From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=rM0N=7W=vger.kernel.org=bpf-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id D6453C433E0
	for <bpf@archiver.kernel.org>; Tue,  9 Jun 2020 11:55:06 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id B44062078D
	for <bpf@archiver.kernel.org>; Tue,  9 Jun 2020 11:55:06 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=kroah.com header.i=@kroah.com header.b="jUFRqrs6";
	dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="FqkFJrFr"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1728926AbgFILzA (ORCPT <rfc822;bpf@archiver.kernel.org>);
        Tue, 9 Jun 2020 07:55:00 -0400
Received: from new1-smtp.messagingengine.com ([66.111.4.221]:56747 "EHLO
        new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1728754AbgFILy7 (ORCPT
        <rfc822;bpf@vger.kernel.org>); Tue, 9 Jun 2020 07:54:59 -0400
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
        by mailnew.nyi.internal (Postfix) with ESMTP id 030BC58016E;
        Tue,  9 Jun 2020 07:54:56 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute1.internal (MEProxy); Tue, 09 Jun 2020 07:54:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=
        date:from:to:cc:subject:message-id:references:mime-version
        :content-type:in-reply-to; s=fm1; bh=4XghQ4ngJrsVa7o3S5D2L5Fpmy6
        lr42o/I7ET5fuZBE=; b=jUFRqrs66EfQdyi4QdpnhZ8Oh+re4JJMZ7Rj7o3r5m5
        +ds97NPJ6VOO/zButAP+XIWrzEIg07/TyOvOKR4mvqSPM2lu7NsVaDwaZIpcouNm
        jt3bszRxaFO3NBtwI7MI3l/ciYYfW3lc4Wtkpeo9LxbqwEKsnFbG/nY3vNSevoLZ
        1k20y3uzc/WZbXTiW93oiP1szsmq0Cmau4Kw7YFEbVQ811iDIcoybCaaM+i0Ac3v
        /OOrV3SQty5MLo4WLavuRef7BabSUwbIj+BNq/uBNe6KIF9yqmYcvr3jSHpnfx+q
        xNuSBQHl6XUVpAcoPCaJ97lW9JEUSBWWnSDxlLzqoKg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
        messagingengine.com; h=cc:content-type:date:from:in-reply-to
        :message-id:mime-version:references:subject:to:x-me-proxy
        :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=4XghQ4
        ngJrsVa7o3S5D2L5Fpmy6lr42o/I7ET5fuZBE=; b=FqkFJrFrPcz+sUJo4ImAAn
        TydrBGBzHIJwHPZo2QXSRonsQsT2Csj4anXD9+8fm/vjgs6Qs85sUG3gTzX5dpVc
        75E776c0zlSmM47kCiMUkyCgwxZC/ZtqG4zoxFHB43ApxojrLzm16cxDW/zvXGYq
        ydg6Vchn9Pde7V5c0ZOiIuYYVypFDM5RcOkgwk9zo/RRG2P77JZD52vppBeX33cx
        eUf0/+JGLzZ2UjYYU/gnorxi6h4Uz4GtvdL8oyuXnXfM/temhQZcHbMIor6ylswu
        HkLEqrE3elOdTpO2grvK7Fjc3o/3MK7TLKReWN3H6zL2pHPZLiMJEgy+5bruIheg
        ==
X-ME-Sender: <xms:j3jfXh9kqVH9-HALDlZLQVT7BENkZoY3hDDhBYhCD4-v7Fy4Y3BcMw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehgedggeeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu
    mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeevueehje
    fgfffgiedvudekvdektdelleelgefhleejieeugeegveeuuddukedvteenucfkphepkeef
    rdekiedrkeelrddutdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg
    hilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm
X-ME-Proxy: <xmx:j3jfXluXnWs_jAK1jDLLMKaQOkMUfXjkIo8paM0MaD5kFP-dodvGQQ>
    <xmx:j3jfXvCLWdH0dctuGUr7cptGmFfiasX18CesjRfXan9IlErMbkq1Rg>
    <xmx:j3jfXleh_fyxlHaxgd1mYPPBZXa8vu7uQWLlYHGxKyqGoNP2E5vcFg>
    <xmx:j3jfXnn7jXQRdKIVOw7K18MEzLZer7ELe2Kuqlv-ZJxua8x3Gj4soA>
Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107])
        by mail.messagingengine.com (Postfix) with ESMTPA id CDD08328005E;
        Tue,  9 Jun 2020 07:54:54 -0400 (EDT)
Date:   Tue, 9 Jun 2020 13:54:53 +0200
From:   Greg KH <greg@kroah.com>
To:     Gaurav Singh <gaurav1086@gmail.com>
Cc:     Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        Andrii Nakryiko <andriin@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@chromium.org>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        "open list:BPF (Safe dynamic programs and tools)" 
        <netdev@vger.kernel.org>,
        "open list:BPF (Safe dynamic programs and tools)" 
        <bpf@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20200609115453.GB819153@kroah.com>
References: <20200609113839.9628-1-gaurav1086@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200609113839.9628-1-gaurav1086@gmail.com>
Sender: bpf-owner@vger.kernel.org
Precedence: bulk
List-ID: <bpf.vger.kernel.org>
X-Mailing-List: bpf@vger.kernel.org

On Tue, Jun 09, 2020 at 07:38:38AM -0400, Gaurav Singh wrote:
> Please find the patch below.
> 
> Thanks and regards,
> Gaurav.
> 
> >From Gaurav Singh <gaurav1086@gmail.com> # This line is ignored.
> From: Gaurav Singh <gaurav1086@gmail.com>
> Reply-To: 
> Subject: 
> In-Reply-To: 
> 
> 

I think something went wrong in your submission, just use 'git
send-email' to send the patch out.

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D3FC1474CF
	for <bpf@vger.kernel.org>; Wed, 26 Jun 2024 07:01:54 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.173
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1719385316; cv=none; b=rhHaLFHX5YTL3o+1TfP49sKwqLefLD8lD7KE4gmikCFwovJvdEx/lwiwtUu2qP5axPJQJs+YAFHY1C0Bf/m+KkZdKaqBewhPO8LqB7QvGbmYsZoR67n7NTNLxsTMxu0Vi9PZVCIRXEN9Dy6yPiZ5Sya7EZDyg0YjgWjRqkzsTZQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1719385316; c=relaxed/simple;
	bh=OGvgc2KneuynUrDgooPLkWmILwuReEjCUK/ToIEB4T4=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=rE/NXdq2r3sOdg2UjlDKawT0ArfOQ686/hV4zyou/mjwK8tFOsiIacP8d9iAZMaKfkWphpjjNvfGMjRUjgvbUup9q7MjgMmPxcOI82TvZ8xYxEE6Hb2BptiLUMaOUiCFGeng5ou2D9MalfiKMSvDymhUPtacQ5lfy1xJUns7bAs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=HbvToHoa; arc=none smtp.client-ip=209.85.208.173
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="HbvToHoa"
Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2ec61eeed8eso33913291fa.0
        for <bpf@vger.kernel.org>; Wed, 26 Jun 2024 00:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1719385312; x=1719990112; darn=vger.kernel.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=nA1x+J+b2IT6ve0HpdA3/HCBu9mWxJI21oPGiFwWMyQ=;
        b=HbvToHoaQpXAe+MERM5s+Hx7HkWGFikkQQt5SThJ/GO4BqKffWF3SlT3v8knqJ/eBE
         EXFRAPzB/3IYS1b85dq+g3ffn7Wf8uJ28MKvsTRX/+aqPbrgUFz6gF6gzCduCHL3HvOX
         jUVakqGQ4NBCwwENAmubV2Vob38WgOdqcMy7VFkf5ab0jfQS10R3B7sH3YoS1JLhGgnZ
         7Xy2yVui1VCSAgKm6OL4dqrpscm/yoWt8nfGSealFFPLnRmxAkVfKFLbGxckYx6FOyGu
         sSn99y2LEtwzLXPWVaJvRE+zrI735ESIk4o3EXRdyn2Mcws2TbMeeLcET1qzAcVG0wxc
         FFVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1719385312; x=1719990112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nA1x+J+b2IT6ve0HpdA3/HCBu9mWxJI21oPGiFwWMyQ=;
        b=ATegayfwqKhWxVkk6w+e8HpC6tEL8lmqweNjTcO8H8Nwn27X1OSya/NfMFxnRawW+P
         RQsQAEe8tSG4evCpeNXwHmgdk7YwAd8gJjOfHaRucQC64zp7l5oak9vZSS+ERqnrSlmT
         Iuf/hV4hpGzo1tcq7PXTOUa4qXIQDmeAX5cqg1hS9khSnbrX3etkcccPI99gf65lJBe1
         qlhYx3cPLPp9zFWwAo5XBKXEavFZzpfb3qSecnXHkNNrK8ey1w2R/Kn3TBVjdYux3enM
         LqY0gr8VJo1iqba/An/FaB4uUkQA/dGrh++9C+vFmZINlo1eC14jUYsx/LNMDa+OiAuA
         tVvQ==
X-Gm-Message-State: AOJu0Yynmtq1dptmpvIdfPjU1dl1IFOOsXr8qQGCQlc0OA1+uHP63bwf
	FJo+4tR+AfXM1OUBWxVx4dMi+sLfXkVi+VqTPyirql7FgxoCMMt1LZ9bEME8tUA=
X-Google-Smtp-Source: AGHT+IEtSqpX4nkQtBjACbvpdud+/3sMmzgR5hW4CEWxYnW1K8+1IXWBWBnIeK8FLwoR8mXLZCm0mg==
X-Received: by 2002:a2e:b179:0:b0:2ec:5685:f068 with SMTP id 38308e7fff4ca-2ec5b337265mr54240481fa.17.1719385312176;
        Wed, 26 Jun 2024 00:01:52 -0700 (PDT)
Received: from u94a ([2401:e180:8840:49da:ed05:227a:7b40:7717])
        by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f9eb2f053asm92434375ad.18.2024.06.26.00.01.50
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 26 Jun 2024 00:01:51 -0700 (PDT)
Date: Wed, 26 Jun 2024 15:01:44 +0800
From: Shung-Hsi Yu <shung-hsi.yu@suse.com>
To: Totoro W <tw19881113@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: your mail
Message-ID: <7occhv45aax2irfmy7ocevanzm5yhtpknz67lyndrf2iq67pve@j5nblmzivwyb>
References: <CAFrM9zuz8Wh5g7ykOkmFXwVdxgB7NQWzDbvv7=CEpEks54GnSg@mail.gmail.com>
Precedence: bulk
X-Mailing-List: bpf@vger.kernel.org
List-Id: <bpf.vger.kernel.org>
List-Subscribe: <mailto:bpf+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:bpf+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFrM9zuz8Wh5g7ykOkmFXwVdxgB7NQWzDbvv7=CEpEks54GnSg@mail.gmail.com>

On Wed, Jun 26, 2024 at 02:11:18PM GMT, Totoro W wrote:
> Hi folks,

Don't have answer to your question, but noticed that your email was sent
without a subject.

This looks like a worthwhile question, so perhaps consider resending?
Without a subject this might be easily dismissed by the maintainers.

Shung-Hsi

> This is my first time to ask questions in this mailing list. I'm the
> author of https://github.com/tw4452852/zbpf which is a framework to
> write BPF programs with Zig toolchain.
> During the development, as the BTF is totally generated by the Zig
> toolchain, some naming conventions will make the BTF verifier refuse
> to load.
> Right now I have to patch the libbpf to do some fixup before loading
> into the kernel
> (https://github.com/tw4452852/libbpf_zig/blob/main/0001-temporary-WA-for-invalid-BTF-info-generated-by-Zig.patch).
> Even though this just work-around the issue, I'm still curious about
> the current naming sanitation, I want to know some background about
> it.
> If possible, could we relax this to accept more languages (like Zig)
> to write BPF programs? Thanks in advance.
> 
> Regards.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jaroslav Kysela <perex@suse.cz>
Subject: Re: your mail
Date: Sun, 21 Jul 2002 10:28:03 +0200 (CEST)
Sender: alsa-devel-admin@lists.sourceforge.net
Message-ID: <Pine.LNX.4.33.0207211024590.755-100000@pnote.perex-int.cz>
References: <Pine.LNX.4.44.0207201136590.8230-100000@cmn37.stanford.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-path: <alsa-devel-admin@lists.sourceforge.net>
Received: from gate.perex.cz (root@gate.perex.cz [194.212.165.105])
	by alsa.alsa-project.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA25291
	for <alsa-devel@alsa-project.org>; Sun, 21 Jul 2002 10:28:36 +0200
In-Reply-To: <Pine.LNX.4.44.0207201136590.8230-100000@cmn37.stanford.edu>
Errors-To: alsa-devel-admin@lists.sourceforge.net
List-Help: <mailto:alsa-devel-request@lists.sourceforge.net?subject=help>
List-Post: <mailto:alsa-devel@lists.sourceforge.net>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@lists.sourceforge.net?subject=subscribe>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=alsa-devel>
To: Fernando Pablo Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Cc: Takashi Iwai <tiwai@suse.de>, Gary Scavone <gary@ccrma.Stanford.EDU>, Paul Davis <pbd@op.net>, "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
List-Id: alsa-devel@alsa-project.org

On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote:

> > > > on a related note, although the above suggestion will fix this
> > > > particular problem, it seems that it might be wise to consider adding
> > > > a parameter order information field to the driver API, so that drivers
> > > > can say "you have to set param P first, then param N, then param
> > > > O". the default would obviously be "don't care", but for devices that
> > > > lose certain capabilities when certain parameters are set, it would
> > > > make things very much easier.
> > > 
> > > agreed that it's good to have such one.
> > > but how to implement this?
> > > from the design of hw_constraint, i don't think it's so easy...
> > 
> > I think that this implementation will create a big mess for the 
> > application developers. Also, I'm not sure, if it's really needed, because 
> > our refining code should already reduce the available configurations. 
> > Applications should use *_near() functions in order of their priority. You 
> > can't predict, if rate or count of channels or any other parameter is more 
> > important for a specific application.
> 
> [not exactly an answer but more details on what is actually happening]
> 
> I think this is what is happening with the current driver (Gary, please
> correct me if I'm wrong):  The application looks at the configuration
> space and selects from it one particular sampling rate. Then it looks at
> the channel count and sees a range of channel counts (10:18 - or some
> numbers like that, I don't remember). The application chooses the minimum
> channel count and the set function fails.
> 
> IMHO at that point the configuration space should have changed the number
> of channels available to match the sampling rate selected so that the
> channel count as advertised is legal (ie: if the selected sampling rate is
> one of the "single speed" rates then the range of channels should be
> 18:18, if the sampling rate is one of the "double speed" rates then the
> range should be 10:10).
> 
> The reverse is also true, if the application first selects number of 
> channels the sampling rates should be constrained to the set of rates that 
> can be supported by that number of channels. 

You've described exactly the behaviour which should be implemented in your
paragraphs. If the current implementation is broken, then we should fix
it.

> If it is not possible to do this with the current api, then the next best
> solution I can imagine is to have a switch that changes the mode of the
> card between single and double speed (that would make the dependency
> between sample rate and number of channels dissapear).

You may look to snd_rme9652_hw_rule_channels(), 
snd_rme9652_hw_rule_channels_rate() and 
snd_rme9652_hw_rule_rate_channels() functions in rme9652.c.

These functions exactly describes the contraints for rate/channels.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id 51B89CA0EF8
	for <amd-gfx@archiver.kernel.org>; Thu, 21 Aug 2025 12:48:48 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id 6036310E304;
	Thu, 21 Aug 2025 12:48:47 +0000 (UTC)
Authentication-Results: gabe.freedesktop.org;
	dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="gy+zDfdH";
	dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="QeoYI1cG";
	dkim-atps=neutral
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32])
 by gabe.freedesktop.org (Postfix) with ESMTPS id 8B76B10E8C3;
 Thu, 21 Aug 2025 09:18:09 +0000 (UTC)
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 57L9DwWN001554;
 Thu, 21 Aug 2025 09:17:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
 :content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to; s=
 corp-2025-04-25; bh=NWJ3/IwVRMsa7/flkStAN6dqCf7RdmUYkZmqIg39G3g=; b=
 gy+zDfdHQ4nd69h6rpp/3M53A+9FGmcKITph4MTdAieOyCOg/jSNKAShoeMw27U/
 11vYZ2t3H9QU7hkYwoUhgVADPdaq1SHDGHSrfs1bGNH+GOQo3kTiWV0+iOHzZDQC
 rKNW+6h4a85UC/LhvBfLU5acRTh3VIEctZ8mIk8oNiqer0JnOwVk2+eO4WcCUKpr
 tb/fDJFnNX0ApAHc+EVJ1DpW2uZ0zkO/2YFqR+nA705eJ6r0ahC3WIcUtEt0roka
 Ujqpt6hPhF9BX1wCXJp/qmvGo0x7W3/h+K8Xci6jpmOnm2LXDjfXXi9mPi/ayw+H
 uhEx0y69pb91lV5uyWY/sQ==
Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta03.appoci.oracle.com [138.1.37.129])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 48n0ttjy4p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 21 Aug 2025 09:17:00 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 57L8VL4F039465; Thu, 21 Aug 2025 09:16:59 GMT
Received: from nam04-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2064.outbound.protection.outlook.com [40.107.102.64])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 48my3rur98-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 21 Aug 2025 09:16:59 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q3ekFOOw7pDOk6k6CDzaZ8K2xs3FQuMi/Zv7i4VHsIhvVd3RVmVJPzf91XJAhHX8BxU+TamzYVzJZ2sOGXOQ/VREUO5qozWRqrjdWXqj7lbr3TAQQ3kR1Ydglpo/ZUEVuzMTSpz3dwLm3zRo2/aquJuSXwsj6gNSjOmS+GpBQRTfVhNv3an2yYO079CUKitQgvUoNfPa7+a2IfrkVWmpEpev23AAAU1LlhBXeS8PMoMTXGHt3l+tpSRsqdY1QRAKzVYXhpW0aqZSwX6SXDHGE1yNawnGEfB0ExTFhfdeFONeOIWhrIuUPY/vo7PQlv/oc6UZ4OX6Oq3o4fUCMbHGgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tDxGh8/YKT34UHYIk1rdkRJMSCthKG3z/0nGGT66Qh4=;
 b=QXtVUmmPYSQBqd+2M9qHlcPPWsAFBt6sKt0UoIy+A2tH0Zl0Xia2jl7+BSs+yrwxout07f6TWP7PNitCSSvjArDs2iYnJhcGbLUDkEV0KacZNlXIieiXC+AX275vPo4c0d/EAkFHMfZktSExTzpDugsWpUTEMvm5rJbMjS3TimNPM8tV1mFWa9K4YadDPq3pwfNrSFLVR2mH+ZmYHJ2DSOxeBtsWEcmKjZ84/OKA6L7kZRv20CWSIrAspOnu2SBJtqcghuN9uqqPUoy5NLSvgqqww3mx4coyJkqKk1BDtxgezQZG6fYO7fSCwRRWY3K1NUR9JKDGpL/P7yL1CgS7Gw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tDxGh8/YKT34UHYIk1rdkRJMSCthKG3z/0nGGT66Qh4=;
 b=QeoYI1cGF96X+tFCG2KJxo6FjAUQB1gbLTAdutBzKGXy9tKOSZGRnRRP4BHSgiq1KsKYTBoygP8NxVMjMrtNgOGomMOpUo4RmvZZVrqlYTTWwkPD6RlzDdx8U9cGvLHRLAoqVAVxdYihNv5taUH0FXrGP59PyiQTOxYAaNPhX9g=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by PH7PR10MB7850.namprd10.prod.outlook.com (2603:10b6:510:30c::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.14; Thu, 21 Aug
 2025 09:16:56 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9031.024; Thu, 21 Aug 2025
 09:16:56 +0000
Date: Thu, 21 Aug 2025 10:16:53 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Christian =?utf-8?B?S8O2bmln?= <ckoenig.leichtzumerken@gmail.com>,
 intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
Subject: Re: your mail
Message-ID: <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
X-ClientProxiedBy: MM0P280CA0064.SWEP280.PROD.OUTLOOK.COM
 (2603:10a6:190:8::26) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|PH7PR10MB7850:EE_
X-MS-Office365-Filtering-Correlation-Id: cdb8d9f2-4cf2-4dea-62a5-08dde09379cc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
 ARA:13230040|366016|1800799024|7416014|376014|7053199007; 
X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?T5p1MnRvANWSHvoobYRZFfFgTslcAZJrlsHQzUXoFmcrc3afuZhbwRQ2cy?=
 =?iso-8859-1?Q?usQmz9un32NzmUvSwo8g1A26YB3FaLtE+isfbcNDr0kDEMYby74dKnMth+?=
 =?iso-8859-1?Q?nrWC+HJMQH2kimcDZDuIXVV9ScHPiyIZVo5oy0Bw2pkPr6a6cFrNsYxCS8?=
 =?iso-8859-1?Q?KsDcf5+Q/fZ8ZKWZPUt/GgYLcfdSMk1yRCTQF4MeokQOn+m7OrVChFwhPU?=
 =?iso-8859-1?Q?LT/jdFzCsQQl50nXQzU9rXITbJ6jlKLRkOt0/NTVoHqB1Q4hjL92E+f+L6?=
 =?iso-8859-1?Q?7Luk4uJqUTsY3GF95wFhHd8zdXdVRn6VRP8AtVm7Ir+z6QeSnUirq6DJqi?=
 =?iso-8859-1?Q?7d9QrXYGnJ9lhVjTfrEhXJam0sPm+sf2CC3ahusJkvdFLdk4tJRw1BDSfv?=
 =?iso-8859-1?Q?cyvW2RIcFzTyTnfGPY3DWiO7YmjmxX54qR7uuZ0g8yBnvdFN5Jhem0f954?=
 =?iso-8859-1?Q?olWpXuR8SHF/jhvp5xr8tYb++bg07Y1VEdKSivxoSf57rTQNlPp4eOBV6e?=
 =?iso-8859-1?Q?VyF/ZjjxWWL6mHvT7JCa3FkVNiqYPFtpldo7mVMao8WZyvi5kmQ5RNaxia?=
 =?iso-8859-1?Q?DhrYnB2iW5m93MWDp9I1jyus1qb+kR7cL9vUy5Sp0wCGxICa6Aj+SZsqE/?=
 =?iso-8859-1?Q?hTQfSGfOZZufXO9Xr1j4Qq9pNyWhkkPBvdWFhzS2yo4r+y3TdVeETfZ5Ym?=
 =?iso-8859-1?Q?6sQYvSlKTftmQEIuj2kH6H4uAEc72ZXXs7J7+XLUCVnYAvlGCvUlIyFvLf?=
 =?iso-8859-1?Q?BSSHpBjvzIPGKxuHhjlUjywykx8/qwDjpvbXQr5hLlNej3KK/AI5D/+w63?=
 =?iso-8859-1?Q?PgWbf+AcbznGNuDGHtiYotO79uU90IgRPP+NL3u/E0lATZ432PZW0BM6rm?=
 =?iso-8859-1?Q?dV1w9HhUtpq0+4MHeDzhvQNhEMsNPfH6+SiIR7J+QPNUBtJG5QP2CY1uKZ?=
 =?iso-8859-1?Q?tSLM2QpLxjTsETFONdr3O+19Gnev7hlQn4DXz0BOdMDsJs7m3FNy0kLL8Z?=
 =?iso-8859-1?Q?3jnSGN2/PFcKZsGNuPAWDgtahTiOws51ssGxRsjm7hk1nChO1Zlh+nyVHn?=
 =?iso-8859-1?Q?rc7uY2y/MF9zDMLTDEN91LS1H0ZzMDPbLbkKzTJaTTfJEGnsvsjt8sHrlR?=
 =?iso-8859-1?Q?9CSJhC4mmauyEcUDn3gEjmx1pifjq8Q6nz8UAtVlrZbHmbe1YQs7VEn3ne?=
 =?iso-8859-1?Q?r+lADYBHeK4kt9c5cl+8wPfPEOyz90Ye6nsvN6oEUMIoh0TvxXFM6th+bP?=
 =?iso-8859-1?Q?EJ7JHl6HBYZ/u4EXfABK+XfJ7zhrRspkvnFRhG2gv20Y+7zu2GvT5k0wMp?=
 =?iso-8859-1?Q?sZg61Kz027mfu45mIBUtz27LwAlw/IwmJk1dNFaOgG8DkxqT26IIf904xF?=
 =?iso-8859-1?Q?n7xm/WOjGerG8tu9aSuQMbieMQ+bDo63ATvbYV2weQGlT+koBC1O0g1SDd?=
 =?iso-8859-1?Q?dDReurmPSZAE8f+rUjC23FsRicPBVAgPOSKXMOEIAIHYKKhmiOx/owe3qp?=
 =?iso-8859-1?Q?c=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DM4PR10MB8218.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230040)(366016)(1800799024)(7416014)(376014)(7053199007); DIR:OUT;
 SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?UpNQT+2dR3D2mzF6alBiTUG3UcWbV+E371Og449zfB8NMKBtFLOQ56XAqu?=
 =?iso-8859-1?Q?YNqOlxf11S1fXASFolwAhmmmHKjOP4VmgJNABZZiHUQgeke1uCk/piamJm?=
 =?iso-8859-1?Q?qXCJmbkTv+bGuEWPfkPDWk2oRBGcah20Lhlbg6PXcH+brOzhljXuwazaNH?=
 =?iso-8859-1?Q?6MzRcP0SXocpxqIQ6jrpXhq7cvB8QGT18uJf6YB095qeWJ3j31Y2YDIrKx?=
 =?iso-8859-1?Q?79mdInzKU6ej7xNV4PVlnhYlkktH4ciLMKRCuLthuCUnByKAu9AjJJqUvu?=
 =?iso-8859-1?Q?iMYK6UyJd4ocawQ43WJEKkZMtzBzu+jzdBNxLTHnZTqTSdVnNR28wTPBSw?=
 =?iso-8859-1?Q?eYivIClX976fKMBEOgSUgQwnoMsJjpQYJe73zo/S12V3jroIqw/HXbP5fw?=
 =?iso-8859-1?Q?SWSS+s4EmmaPRVlpph7p+cVBn5F957yIhzQVhOb9UH/hYNQPJ37nypazi0?=
 =?iso-8859-1?Q?zPrWA+W3GacOUkvfaB6lNE4fwvrlDZ9S26CG8QpABdgxW/6fUEzn7BO5D/?=
 =?iso-8859-1?Q?DcfZvlLhvICRXXBamvv+CoUYaCvx5YWdnDwhmbUnt+vdhrh7kckqbcj/UH?=
 =?iso-8859-1?Q?oAoluTI3HpUHire5jxEnMgnA1WKRU1SWypibb2Ln5UqmIuIHJmmZjnba0u?=
 =?iso-8859-1?Q?vT6uhwJ8G7p7b+Xr1YWIH7KbhV7QArKP6Lv9VLfIC5+JhrxPzwx80RfhY6?=
 =?iso-8859-1?Q?7gksigttVvGWYitr+oMcoY3muNJmMLerdZek3ykcOyDydiP6NBW+IRUSEs?=
 =?iso-8859-1?Q?yGQvPjY19ivb5jizklznGb4+fDpPcX4RFy52gvd0lavRG4WvGhka9EH/B8?=
 =?iso-8859-1?Q?o8LVrH9aQqQXZ53RCfJyB46ZYCUVV88iK86ZsbVw5iCDhivgGxiE9bMgzz?=
 =?iso-8859-1?Q?aX5flUKNuPLLHRx1PDNfaVtYyuShQ22779x6mRzXSWeCS8d7qsQN9nS1yt?=
 =?iso-8859-1?Q?YU4KysOkZyx8uVHb4CfeQJQ23bvUPW5kfFrasqAmxcu2Z9KImduyYS8HjR?=
 =?iso-8859-1?Q?3evtCsfMZA497svqCw4cORkOPFcGzW4zLJdec54I6JI6TU6ijx7Qb9qak5?=
 =?iso-8859-1?Q?P7icSbV5X6T7akDcno7RukTkqNmkVoItGv8q0afQjbb5pgOZSeNxcuift6?=
 =?iso-8859-1?Q?mAGCVXTaQW0cO3y1wSyiiRpayDgSJbhFvy9Yc2tR7LfdCLAAoiMgbLWVY2?=
 =?iso-8859-1?Q?xLbPs2hq8q3mYWIb3+MNyinN4UhF9FYUd4UdqhUpKxDZxrtY9e6zmX5Vhh?=
 =?iso-8859-1?Q?ihCp0tVu2SA6AXwBh8uikyqSqLwWS8YFEwSMziHyRc5Cv7Pipu7fXZ67+h?=
 =?iso-8859-1?Q?bc0DZHg0JlrbMFbqfggMLghJJFH0XTZLXvcdFkDwxgEv16k8L3Lsasd83l?=
 =?iso-8859-1?Q?Oh89rR+prZcGeqTaMF+AiPeTErunrRKZVgAXZHuVLNiEvaKzobiMpRdaHZ?=
 =?iso-8859-1?Q?6sneEvRcukg1xGWC/zCrO4zrB+yP7vwNCjiWY2IZ0YGfbenlFMu7RVG5vR?=
 =?iso-8859-1?Q?IOjCsbP7PXyp9C3qaR7V6mD/qT6NPgOnnxwaM8+PmDKT4fF/eWP5AylqpY?=
 =?iso-8859-1?Q?6w6AmBsu+u3BtEO6VfIjyZV0p+ipdzgngNoXkNN9+V2u38AIOrC1zL1VRN?=
 =?iso-8859-1?Q?3t3DOVAhWA6MR/7hmb8MCvgaPEkg8GUp8qxp7JUINkd5gP5kp8glK23A?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:  
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cdb8d9f2-4cf2-4dea-62a5-08dde09379cc
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2025 09:16:56.5341 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SFphe0W6FeDRFU5sPnubOWa8cVaaTE6xlpA4ftiuPzJmbnacMyBT7nRuBncpk4ImUiJB1X5UNlUZN7blGNgKGLMptK5oDtb/bRxQgs6CA80=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7850
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-08-21_02,2025-08-20_03,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=950
 phishscore=0
 adultscore=0 mlxscore=0 bulkscore=0 spamscore=0 malwarescore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2508110000 definitions=main-2508210072
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwODE5MDE5NyBTYWx0ZWRfX0o1A0w+HpPTU
 3GKEe812zJMjmGC6Spv+lQJHyXbO7fwqDiEYWG1WvIirT+sAvT+WA9CTX907HiFaE5ztOtAVxnT
 XhSXGvwGT8I8Sq6KgHC3C16pmlAjZeU++4x1o0qvLg2b6tHDtCiG43ZIXiMgZaowslC1/we/rqH
 cURoRXP6tHLgvgFFwLLo9j/1lAB3XK+ab2vvnG65TsQKVbURqICRfRSsJrueC9wEf4G3YDju4qH
 JLOGdf3YGNOfVPObstKNtXIyceLtYu0j4kOgtw0c6QOW2GjVvjm3xtp33qtr8jMF+pcuU8oiM/R
 TlVTmCqjswntQ/knPKRNuuChbn5EPOrv37CFVqNtex2+pyNfhb+Oe+cc50mYKeiXnjjr0k1MkCg
 4RgooXI1lnbeidLAcyTLx1lOXCgw7Q==
X-Proofpoint-GUID: _7r3uL9rsuBMbHJhiopNLYDK0M6Xm6VZ
X-Proofpoint-ORIG-GUID: _7r3uL9rsuBMbHJhiopNLYDK0M6Xm6VZ
X-Authority-Analysis: v=2.4 cv=V94kEeni c=1 sm=1 tr=0 ts=68a6e40c b=1 cx=c_pps
 a=WeWmnZmh0fydH62SvGsd2A==:117
 a=WeWmnZmh0fydH62SvGsd2A==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=8nJEP1OIZ-IA:10
 a=2OwXVqhp2XgA:10 a=GoEa3M9JfhUA:10 a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8
 a=g1ruWK-PMPiBxAydvZ8A:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Mailman-Approved-At: Thu, 21 Aug 2025 12:48:46 +0000
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

+cc Liam as he's also had some fun with PAT in the past.

On Wed, Aug 20, 2025 at 05:23:07PM +0200, David Hildenbrand wrote:
> CCing Lorenzo
>
> On 20.08.25 16:33, Christian König wrote:
> > Hi everyone,
> >
> > sorry for CCing so many people, but that rabbit hole turned out to be
> > deeper than originally thought.
> >
> > TTM always had problems with UC/WC mappings on 32bit systems and drivers
> > often had to revert to hacks like using GFP_DMA32 to get things working
> > while having no rational explanation why that helped (see the TTM AGP,
> > radeon and nouveau driver code for that).
> >
> > It turned out that the PAT implementation we use on x86 not only enforces
> > the same caching attributes for pages in the linear kernel mapping, but
> > also for highmem pages through a separate R/B tree.

Obviously this aspect is on the PAT guys.

PAT has caused some concerns for us in mm before, cf. David's series at [0].

[0]:https://lore.kernel.org/linux-mm/20250512123424.637989-1-david@redhat.com/

> >
> > That was unexpected and TTM never updated that R/B tree for highmem pages,
> > so the function pgprot_set_cachemode() just overwrote the caching
> > attributes drivers passed in to vmf_insert_pfn_prot() and that essentially
> > caused all kind of random trouble.
> >
> > An R/B tree is potentially not a good data structure to hold thousands if
> > not millions of different attributes for each page, so updating that is
> > probably not the way to solve this issue.
> >
> > Thomas pointed out that the i915 driver is using apply_page_range()
> > instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and
> > just fill in the page tables with what the driver things is the right
> > caching attribute.
>
> I assume you mean apply_to_page_range() -- same issue in patch subjects.
>
> Oh this sounds horrible. Why oh why do we have these hacks in core-mm and
> have drivers abuse them :(

Yeah this is not intended behaviour and I actually think we should not permit
this at all. In fact I think we should un-export this.

I think the hold up with it is xen, as the only other users are arch code.

Probably we need to find a new interface just for xen and provide that just for
them...

>
> Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird
> crap to page tables because "you know better".

Yes. This is just not permitted for general driver usage and is an abuse of the
mm API really. Esp. when the underlying issue is not to do with core mm...

>
> All the sanity checks from vmf_insert_pfn(), gone.
>
> Can we please fix the underlying issue properly?

Yes, PLEASE.

>
> --
> Cheers
>
> David / dhildenb
>

I will add this xen/apply_to_page_range() thing to my TODOs, which atm
would invovle changing these drivers to use vmf_insert_pfn_prot() instead.

So ideally we'll have addressed the underlying issue before I get to this,
because this really really shouldn't be something we allow drivers to use
generally.

Cheers, Lorenzo

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id 6AB18CA0EEB
	for <amd-gfx@archiver.kernel.org>; Thu, 21 Aug 2025 12:48:50 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id B418010E980;
	Thu, 21 Aug 2025 12:48:47 +0000 (UTC)
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by gabe.freedesktop.org (Postfix) with ESMTPS id C7E9410E0E7;
 Thu, 21 Aug 2025 10:16:54 +0000 (UTC)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id CF0DE61157;
 Thu, 21 Aug 2025 10:16:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1503C4CEED;
 Thu, 21 Aug 2025 10:16:50 +0000 (UTC)
Message-ID: <95dcb699-2add-46b0-959f-c2331cc775c1@redhat.com>
Date: Thu, 21 Aug 2025 12:16:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: your mail
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com>,
 intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
 <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
 <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
 <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
From: David Hildenbrand <david@redhat.com>
Content-Language: en-US
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 21 Aug 2025 12:48:46 +0000
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

On 21.08.25 12:05, Lorenzo Stoakes wrote:
> On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
>>> I will add this xen/apply_to_page_range() thing to my TODOs, which atm
>>> would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
>>>
>>
>> Busy today (want to reply to Christian) but
>>
>> a) Re: performance, we would want something like
>>     vmf_insert_pfns_prot(), similar to vm_insert_pages(), to bulk-insert
>>     multiple PFNs.
>>
>> b) Re: PAT, we'll have to figure out why PAT information is wrong here
>>     (was there no previous PAT reservation from the driver?), but IF we
>>     really have to override, we'd want a way to tell
>>     vmf_insert_pfn_prot() to force the selected caching mode.
>>
> 
> Ack, ok good that we have a feasible way forward.
> 
> FYI, spoke to Peter off-list and he mentioned he had a more general series
> to get rid of this kind of [ab]use of apply_to_page_range() (see [0]), I
> gather he hasn't the time to resurrect but perhaps one of us can at some
> point?
> 
> Perhaps we need a shorter term fix to _this_ issue (which involves not
> using this interface), and then follow it up with an adaptation of the
> below?

We need to understand why PAT would be wrong and why it would even be ok
to ignore it. Not hacking around it.

FWIW, I just recently documented:

+/**
+ * pfnmap_setup_cachemode - setup the cachemode in the pgprot for a pfn range
+ * @pfn: the start of the pfn range
+ * @size: the size of the pfn range in bytes
+ * @prot: the pgprot to modify
+ *
+ * Lookup the cachemode for the pfn range starting at @pfn with the size
+ * @size and store it in @prot, leaving other data in @prot unchanged.
+ *
+ * This allows for a hardware implementation to have fine-grained control of
+ * memory cache behavior at page level granularity. Without a hardware
+ * implementation, this function does nothing.
+ *
+ * Currently there is only one implementation for this - x86 Page Attribute
+ * Table (PAT). See Documentation/arch/x86/pat.rst for more details.
+ *
+ * This function can fail if the pfn range spans pfns that require differing
+ * cachemodes. If the pfn range was previously verified to have a single
+ * cachemode, it is sufficient to query only a single pfn. The assumption is
+ * that this is the case for drivers using the vmf_insert_pfn*() interface.
+ *
+ * Returns 0 on success and -EINVAL on error.
+ */
+int pfnmap_setup_cachemode(unsigned long pfn, unsigned long size,
+               pgprot_t *prot);
  extern int track_pfn_copy(struct vm_area_struct *dst_vma,
                 struct vm_area_struct *src_vma, unsigned long *pfn);
  extern void untrack_pfn_copy(struct vm_area_struct *dst_vma,
@@ -1563,6 +1584,21 @@ extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
  extern void untrack_pfn_clear(struct vm_area_struct *vma);
  #endif
  
+/**
+ * pfnmap_setup_cachemode_pfn - setup the cachemode in the pgprot for a pfn
+ * @pfn: the pfn
+ * @prot: the pgprot to modify
+ *
+ * Lookup the cachemode for @pfn and store it in @prot, leaving other
+ * data in @prot unchanged.
+ *
+ * See pfnmap_setup_cachemode() for details.
+ */
+static inline void pfnmap_setup_cachemode_pfn(unsigned long pfn, pgprot_t *prot)
+{
+       pfnmap_setup_cachemode(pfn, PAGE_SIZE, prot);
+}


There is certainly something missing that the driver would have previously
verified that the cachemode is as expected.

-- 
Cheers

David / dhildenb

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id 524E3CA0EF8
	for <amd-gfx@archiver.kernel.org>; Thu, 21 Aug 2025 12:48:54 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id DACCA10E982;
	Thu, 21 Aug 2025 12:48:53 +0000 (UTC)
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by gabe.freedesktop.org (Postfix) with ESMTPS id 57B6310E8DB;
 Thu, 21 Aug 2025 09:30:51 +0000 (UTC)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5C11B5C5CF2;
 Thu, 21 Aug 2025 09:30:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F55DC4CEEB;
 Thu, 21 Aug 2025 09:30:46 +0000 (UTC)
Message-ID: <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
Date: Thu, 21 Aug 2025 11:30:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: your mail
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com>,
 intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
 <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
From: David Hildenbrand <david@redhat.com>
Content-Language: en-US
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 21 Aug 2025 12:48:46 +0000
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

> I will add this xen/apply_to_page_range() thing to my TODOs, which atm
> would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
> 

Busy today (want to reply to Christian) but

a) Re: performance, we would want something like
    vmf_insert_pfns_prot(), similar to vm_insert_pages(), to bulk-insert
    multiple PFNs.

b) Re: PAT, we'll have to figure out why PAT information is wrong here
    (was there no previous PAT reservation from the driver?), but IF we
    really have to override, we'd want a way to tell
    vmf_insert_pfn_prot() to force the selected caching mode.

-- 
Cheers

David / dhildenb

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id B7936CA0EEB
	for <amd-gfx@archiver.kernel.org>; Thu, 21 Aug 2025 12:49:02 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id 57EED10E988;
	Thu, 21 Aug 2025 12:49:02 +0000 (UTC)
Authentication-Results: gabe.freedesktop.org;
	dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="mPv9MjaO";
	dkim=pass (1024-bit key; unprotected) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="BsiUNBFM";
	dkim-atps=neutral
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32])
 by gabe.freedesktop.org (Postfix) with ESMTPS id 5B2AB10E131;
 Thu, 21 Aug 2025 10:05:27 +0000 (UTC)
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 57L9jpi1019835;
 Thu, 21 Aug 2025 10:05:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
 :content-type:date:from:in-reply-to:message-id:mime-version
 :references:subject:to; s=corp-2025-04-25; bh=1p/ljejplOhmFsx8Ny
 CEQuZ7fLxWKEkQuyyzj8Ybq+s=; b=mPv9MjaOC1BybflYE4ALLUfu2TDle/YdMu
 xt4iVLVI+13eO26SGtYb1+XH12lvBqp9lZjGGlaFd+Crg+EbzdrByeWMjtdgWfDU
 sFsGNtq6HV28ml5p7sLqMjM9BdvLh7F7A6HPYsqCtC2vrlXuq9tjilIn1BdXxgaj
 eNo+F0Zen8iFtyOMf3QadqqOtXem7924sTHjkRdMf2nkx8tth2BvGy3Nj4w/htVh
 h4vWfrIm3rBFq+JfHZCat9FviuoWsnkn4pnUxOLa2RErLx6hNWAV0hql2OI3HoAz
 IHxD/FqBMy1SnWBPbWh9Ii1Wy21dRwf7aXLkGZuUT+fJw3qOv6hw==
Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta03.appoci.oracle.com [138.1.37.129])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 48n0tqu7eu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 21 Aug 2025 10:05:16 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 57L9dTKG039497; Thu, 21 Aug 2025 10:05:15 GMT
Received: from nam04-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2053.outbound.protection.outlook.com [40.107.101.53])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 48my3rw1sy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 21 Aug 2025 10:05:15 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dx2gwMSddbbp3lrAljaV3b0pX+8HV5hBGArRKquKKKSrrJKOQ+zPQPeA0TIe2t5ulcxpOmccCZj3CXVzYDqB1L+EPu3GAzUH0CzN85GAF7EGlC11EPFFtp+ggIKQTWVzDIpyLsuVKk5WDZ9Mia6BaIUFOxOTSGln/Npe9aBTjObi8jDUCUGVKT69sAYfiIRlhEtqL6eHyOavrt+Zb+FsLGKexoFkUjwpBsoQJm2hZ6dFlb1AAYOCzQ+eHRiVGbu5GO3nn6DvG+Ae2R7JfDHT20E8rsWjs5NsVpmykWu3wustTaw2XZqTEGBSSSLlvOJuGinBugfd2YQzgJWE/4dg9g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1p/ljejplOhmFsx8NyCEQuZ7fLxWKEkQuyyzj8Ybq+s=;
 b=emg/gc0PCEc+ns6/zbV3eVjCJZ4mtO12M5LTZ6YpmMcCPbRbVIo/x8JCwepERu7HTSO7kfX7+TABrdD6TiIYbRzGIiG9lwtAVL6xqGGvJJI0A446mtfBCd6uWK6yXC38C2Gq3DOFmIyO+M3QP9y+Uc+VFMmYp77AWTSwLZV1HlwqzvDXjhb26w/rDucDtNV2eGxfWEjIRnYOk0/ZQnGPuvkmw7poRpTJsUAlO3+Gpg1JAXve07Vsvw5apsl7LFdFBVakdsr0Lo9sJlYGvvl47FfpiKMpTEHHHM8Jd+RwWbxTze+9PgTGamL5D/Dfls3XlCgON8mf9YTZJ7eFvVAIeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1p/ljejplOhmFsx8NyCEQuZ7fLxWKEkQuyyzj8Ybq+s=;
 b=BsiUNBFMZoXcnvJmerSnbyfl3JEfx9nyDfIQds/5JJc190TGkp3YN3kK560qiR7hlzdrF823gjG4MnP3SyM4Q6wv542ELG/SamLnL7j6HaW3OT5m9nN3TPpfjXAa85NM2df0B66Lpw/Yj9pOMS+HfJXG+mMyH0e2VPg/0Vdhtck=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by PH0PR10MB4758.namprd10.prod.outlook.com (2603:10b6:510:3c::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9031.25; Thu, 21 Aug
 2025 10:05:13 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9031.024; Thu, 21 Aug 2025
 10:05:13 +0000
Date: Thu, 21 Aug 2025 11:05:09 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Christian =?utf-8?B?S8O2bmln?= <ckoenig.leichtzumerken@gmail.com>,
 intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
Subject: Re: your mail
Message-ID: <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
 <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
 <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
X-ClientProxiedBy: MM0P280CA0044.SWEP280.PROD.OUTLOOK.COM
 (2603:10a6:190:b::12) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|PH0PR10MB4758:EE_
X-MS-Office365-Filtering-Correlation-Id: a3c64fcf-2fdd-45bf-87d6-08dde09a3849
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024;
X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?bXpwPk+Cp0IXlSxop+9B89g/hqFSDrkgf7pWqDEX/AaYNeS/rTWtao2PU217?=
 =?us-ascii?Q?7IVMePMRPcbNIZcWS9paLCy+Qj/s4W3lRKzgBojP/OJEd52sKb2c/AXCYwuP?=
 =?us-ascii?Q?T/EzZMuWrgRz4F88OWeUB1o3JaW4thptLYbziq0zsKmFEgMiJLY/FzFXC+ur?=
 =?us-ascii?Q?6SU9Pkn5Vj91U7zQshLULQ822NrDaxJn0njHr0Cf3EuDr65/Won3csr8/JIW?=
 =?us-ascii?Q?48kqbARSOZp7j3AMYsjtyGOUcrXDJHUjouAnnF4KEkiEyg7QCQW0od522jo5?=
 =?us-ascii?Q?5t3+cj3cMj8wF/lh0zc8lQ+40dCW9sn8z8HF35B7oNxnZWA/MwqKUCShAUXO?=
 =?us-ascii?Q?c6Jl6fWtjSKozF8zM21amaKoK4aPkIuyyOtPFQTEMQr5HrnfVVWUq10W6p5s?=
 =?us-ascii?Q?DrWNLy0PvSs5OiusxDIA/GYu4ofsBvoWeuBkB0wU6TUs8jQBB/87cNZszrFf?=
 =?us-ascii?Q?2qMnOQ+eZXnDKEDPB55rqS7eTWgVkGLu0xZXKGDmwnq6OVha0jBk7NPofjQ2?=
 =?us-ascii?Q?nSMv7aBjvsWTO5ItnkZPo1nbS1zeZzNsaDpgvuGkxrLTA5QFiQPZvd4h+7qG?=
 =?us-ascii?Q?XmcF6Kili1kI3ZBPplKpsB0RucZw49HLKrQFi4aDxOcPNmxNKkJs0daV1AhM?=
 =?us-ascii?Q?2C70VT5Duhi/rfavBxIU2E2ASCSP2vkdSgxwyBYwkGPVncuhitsSd9coRYpb?=
 =?us-ascii?Q?fhZCQie7lJXh8ywxQ3U55x2u/GTk6vMKoPIOcvO3dJ0FeUMDjNi6Pl2WvxMR?=
 =?us-ascii?Q?VksdNUYLyYX8SVn04EDziYzDmxEi61qFQskMOCyx2bsAojx/I9w2uWV3HGPP?=
 =?us-ascii?Q?MRw09CvFkPFxLuwk9A7QGMUzJLx3F39nm8/6LZaUs1ovqw79KNujEvixdf2a?=
 =?us-ascii?Q?YTmjwNxNl+ox/eScQeRpmyqxHVqNt18TsJTv6ubi9HCZGRfa6D7QOO7bwDGf?=
 =?us-ascii?Q?d/CjEYDbwl71QrNQ+/mcoXNgYc/3ZaKp/pB9rzIdeouRzxsBJto+FIkgoMpE?=
 =?us-ascii?Q?+i21xvVJGmE/yqYJQqprFxUbtHGrAL7DHCxU3R+BWHjUMyZ/O9leIxfrbWcQ?=
 =?us-ascii?Q?LyjoVAX7qvBVCRtHlBjmuJDr8Vvy9mZRSzVanBW6sAM6YTQ0XuCFH/+94hab?=
 =?us-ascii?Q?ercecuEP856NZldhMsenRprA+TtGIE/a9zLwcVO0ErQqvkh9ecSX4MrgXh6N?=
 =?us-ascii?Q?r5dljHUYrznRPhiF3MCOcNnhRden5yLjhr/mCY26bbiR4o4mujrQiMLAb77P?=
 =?us-ascii?Q?s/eUIWE6jywt4BPwNuU5baZEU1bEajA5Ax8gtuNeT39c8U2sTiXHd/lpP4FE?=
 =?us-ascii?Q?XWZmPqBOx61FMLHoR0L31Pi8Xtsol/J4ZVdU1oYSz1Bue6v7SNvLdFGpVtSt?=
 =?us-ascii?Q?igtdFK/OiizDWlbUV++9hpwTA7cCj4HYZSAR5nXCW+/no6qRyds/Bi3H2N8T?=
 =?us-ascii?Q?9gIuz9mU7AA=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DM4PR10MB8218.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230040)(7416014)(376014)(366016)(1800799024); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bQnajexhJo2niuVts5Ma4QTSTbNzGrgfL7UHx8CrMDAnqZ1HCT2LeVXoel2z?=
 =?us-ascii?Q?mkBn887GNDyUczgT1vMUpQD+rUDQ8tyPq/ZSqYpt0OigIfE9g00AIS6Yu/7t?=
 =?us-ascii?Q?r2rPdzCHFpUBIqmfjhkQEG2Y5C4JnHD+HuYh3bycGe9Gb/d/3roFGbShvGJx?=
 =?us-ascii?Q?dTiya2bTM5PNyjlbt2G8rVKAitOoJ5VBYkn01Qa0xt+zis/GcBNlpGCmVzLR?=
 =?us-ascii?Q?J5HdzQAQz7S+HzbSdeI2uGh/tUsUbzuxPsBzK7ElS4uJcKHzTb17Q4LL6zhe?=
 =?us-ascii?Q?hESiA2L/7byjmlN+R1OH5TyneoZ6kXnkw9eiYJzRko7g441E+wgY6ci9DPeW?=
 =?us-ascii?Q?dOZ1uLUoPAFe60KN5CYgqNEzj+82GSFpP7D9mIL3YnTjgz1DNM9QAYU4w67C?=
 =?us-ascii?Q?6Kw/EnhUrcCXwgR3BGGZOCLj51rti1BEPQsngoR8eIUq9S+oZRFZeyMiuaR+?=
 =?us-ascii?Q?gbIvnkrXw7vaKFGzt+hoF0XoOP6CoTj33zZAK2TdxaDsALStKbzpQ6GpGsZc?=
 =?us-ascii?Q?AtKsQtUsecIwxlVVQPeX65J8WND+XPL9nWsgmf98Cf6hzMPIZgHyk0i1Dd87?=
 =?us-ascii?Q?0o3+zghKAu3ZV5UEX5ybVKp9ky/usJyPEx501/gxVpE3DBBUuz6bAOgDNI8O?=
 =?us-ascii?Q?XNkdYZMpn/a2sYmIRJxqWdfKiLDIADlBbVfEuOKRrN4KdiS+XNoay/3b595s?=
 =?us-ascii?Q?LlKB2P3AztidH1zdW8i4Ta6Gu6J4ojNm+P0HoPnHIQcyZC7BhT2bqPeul2cc?=
 =?us-ascii?Q?I0sn8RCOJqmF3L5VypnLUtUgGAhQP82E5NvG7roAngI7NdZMfEkZvYGmrj4u?=
 =?us-ascii?Q?ILfQZwS8WiL4qBUdhGQR7CQ/vLhjbyNpIWuwqQvQm4DUuDGVWB5rKUHybB5O?=
 =?us-ascii?Q?pdZKsv0h40PrG6OJ6kqR2DCKvaSIx/P7vNNwb+3TF2cyYNK70je6zF1yZirx?=
 =?us-ascii?Q?r4q7ZiuhrED2XJ9nzEuTEJHFadesRd9KwCyVJ8B0HjL24fRiQxWwmD0t1Rrh?=
 =?us-ascii?Q?WRjMiRBTiYWJgi1Z/9uz1XaxDU18cFyipgnMWhi2z7Bzp29s9vR9qHwiet7l?=
 =?us-ascii?Q?a0iq16qj0SG54fCUXOvl5UlsR86sH9856R4D1FawTJUFhDaHz773ALvcHI1P?=
 =?us-ascii?Q?zCKb5mhfTnFwbKFNBnTj3I4Z/9gkGuJg30MQ2f6XIuXf09vS+17cWvwkoljJ?=
 =?us-ascii?Q?KUF+JUPZv5WymC5SX8nDwAPUj6Ju9ajiz7ReByUq7wriLh/ynwia2tL02/Ki?=
 =?us-ascii?Q?8XtQIWiX8YOlkNDVxPdjyQ7yEIJ7dIfiilCB9TeV1xxo6i4+B8xhgoq4Gyg0?=
 =?us-ascii?Q?chahJDIkJ9E3kBeBPwMAOwMOpfCqnzb4B5P5KBDlrHy2+4xcKpSgnpPtF1lo?=
 =?us-ascii?Q?YPlcp8GgnQC2H3b0GdAhPVVCB+kherAIqanQSS+qOwDv8rS2SlJloBzCPtyM?=
 =?us-ascii?Q?mXYp8rDLgdCMtt3DbHZNg0qnSL0nIx9TGEiwJdeGlXkwq25tv8AG2h6SikYn?=
 =?us-ascii?Q?nEEEqZAyQuRc8K9EzPGQUbJIm+v1O3ugq2YCz91S+mvMB6ZcSPcMWAQRnJdz?=
 =?us-ascii?Q?z/Go/+1gjwnKDaLw5B4/mM7CIbe/mMz/oigjhf37r6n5bRx6CTYFioHR8A86?=
 =?us-ascii?Q?ZA=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:  
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3c64fcf-2fdd-45bf-87d6-08dde09a3849
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2025 10:05:13.1086 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WW7cEyxeEaT1r2JIvDoy1gDAnURR60VETwlsLIGBdbCD6Z3rCVLemjtnp72Krw4vcYhhMWNVhw6CK2JbfLp6KwBXApNG+C3pVEOQCEgplOg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4758
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-08-21_02,2025-08-20_03,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=613
 phishscore=0
 adultscore=0 mlxscore=0 bulkscore=0 spamscore=0 malwarescore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2508110000 definitions=main-2508210079
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwODE5MDE5NyBTYWx0ZWRfX6Dgd0n4YFf9N
 Yzx9RpwYGUwbDZBKqWOE6Wyd+9aDDOd8v+xE/lGGn9tIxeqx/b7l1Q8/xXhAcxeNID1vPVniVhM
 ATgpiyhSJYYZgTGHaBib3+8ZNQJmYsxeTC6FMYlyqpj3dgN91kazu0C/N6L17iZzTJQerpCvwb6
 1pAQM2mF5yjsvLRV6keC6ytzrXpWgZhhRKSYwiIeb6+F6spl0UWSYaJkBovaLFWb4IYDCs/07SK
 e60oMBHuFzDjLaky1PbxnEM8vADmgUmfV/T57u8QEsuMH6NsyDfk9xSMHAhJ5ihFkyEu3ihrq1r
 44TaxQQIoS9QtMwbhZmi5eIjvobJYJ4uBmDVRn8IPh1bPt3aPK78w2zxKjWLA5vc9CnyEl1Y9g1
 Ojg/NtDWxsMDdSWEKg0N1vGBy8o6Eg==
X-Proofpoint-ORIG-GUID: sRVq0ZWLg_ezG0v2xiFImryV12WMesau
X-Proofpoint-GUID: sRVq0ZWLg_ezG0v2xiFImryV12WMesau
X-Authority-Analysis: v=2.4 cv=K/p73yWI c=1 sm=1 tr=0 ts=68a6ef5c b=1 cx=c_pps
 a=WeWmnZmh0fydH62SvGsd2A==:117
 a=WeWmnZmh0fydH62SvGsd2A==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10
 a=2OwXVqhp2XgA:10 a=GoEa3M9JfhUA:10 a=VwQbUJbxAAAA:8 a=JfrnYn6hAAAA:8
 a=_JUs_0rQ0FDngYdaXIoA:9 a=CjuIK1q_8ugA:10 a=1CNFftbPRP8L7MoqJWF3:22
X-Mailman-Approved-At: Thu, 21 Aug 2025 12:48:46 +0000
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
> > I will add this xen/apply_to_page_range() thing to my TODOs, which atm
> > would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
> >
>
> Busy today (want to reply to Christian) but
>
> a) Re: performance, we would want something like
>    vmf_insert_pfns_prot(), similar to vm_insert_pages(), to bulk-insert
>    multiple PFNs.
>
> b) Re: PAT, we'll have to figure out why PAT information is wrong here
>    (was there no previous PAT reservation from the driver?), but IF we
>    really have to override, we'd want a way to tell
>    vmf_insert_pfn_prot() to force the selected caching mode.
>

Ack, ok good that we have a feasible way forward.

FYI, spoke to Peter off-list and he mentioned he had a more general series
to get rid of this kind of [ab]use of apply_to_page_range() (see [0]), I
gather he hasn't the time to resurrect but perhaps one of us can at some
point?

Perhaps we need a shorter term fix to _this_ issue (which involves not
using this interface), and then follow it up with an adaptation of the
below?

Cheers, Lorenzo

[0]:https://lore.kernel.org/all/20210412080012.357146277@infradead.org/



> --
> Cheers
>
> David / dhildenb

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id AC0ABC8303F
	for <amd-gfx@archiver.kernel.org>; Mon, 25 Aug 2025 18:35:33 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id 34BDD10E52F;
	Mon, 25 Aug 2025 18:35:32 +0000 (UTC)
Authentication-Results: gabe.freedesktop.org;
	dkim=pass (1024-bit key; unprotected) header.d=amd.com header.i=@amd.com header.b="EovErRZE";
	dkim-atps=neutral
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2078.outbound.protection.outlook.com [40.107.223.78])
 by gabe.freedesktop.org (Postfix) with ESMTPS id D8FE510E283;
 Mon, 25 Aug 2025 18:35:30 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lERs2WCSv9ENhtg9XfkRj63S3VPe4pWlNJHGrK5kIf8QZx3DFe3P6e9SnyoMgHgPC/90SU7n68s1bF/jkbvUALHMqw5dQLJML0jpP3Rmv3cA15UjD6lXbUPJ3eFQ84Ndo8ybRoUs6QmS6v2rmhuYBfik649sKHqzqylzBlJv1sGJsvSMsX7enK9vDfdk5L0f9MET0PhL+GJrKpeUEX+BOSSItAL1xCJTOU2kTI3VdJLShwKnC4b8fjeUAhaSXpMwzxTwyZXUZDOL17LUguF4yJjvSJUHMfYSQ9uKhOkIRPR1DOIwXNcuBE0/UgtIXyuGlz8yxLWCk9pP2oR5bgv5pg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ie0TPe8kWFdzwdIY137WSlgVUhuSj61ER/RdXNrmM38=;
 b=jddo7vZPYmVQWl0tgT0jGg6m99Dnoox6K3Qk7Jx2UOgcCken99Xm4mhaxV42PaAIpqthgxKam6q64Nkc8+lLQFnx64OBGbugDbOBuWnfrr3zlr/6zgpQav8QF+q9peE4eYPWa6WHQ5k2ywzCNlpp1rMh+CqDIc+hV3iiffFwyN105vcrUzlZ/ZYKomvpPYKfLHnhXPUMYLeGFtsxESEURtjIOPJ6u2wTbttlLoUdEa63fxdAITQmTqSZXOsF6EewhFD6dfNT7/CowdaLBv/V4OgHmA+X1lCdZcIx0Red8T4cdX+t3dr407MpHCk2TrCKu+ktCvd3wCD8fMoI0onGFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ie0TPe8kWFdzwdIY137WSlgVUhuSj61ER/RdXNrmM38=;
 b=EovErRZEgx51PFm/zgL5HOCRcgIb2489PW5lgkJ9MTcWtkE9ob0VSJ+/Qi8DpGc0yXNpBPc/Uqx7Ur/HXjrqVpj2UUS2sYVht3jSKsY505PKY3grmXw5HXqf7r6M9f0wy+uzfXiOyxSGFg1qXXXApvJsh6dY3cGBIV+2noP20zs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Received: from PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22)
 by SJ1PR12MB6171.namprd12.prod.outlook.com (2603:10b6:a03:45a::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.17; Mon, 25 Aug
 2025 18:35:26 +0000
Received: from PH7PR12MB5685.namprd12.prod.outlook.com
 ([fe80::46fb:96f2:7667:7ca5]) by PH7PR12MB5685.namprd12.prod.outlook.com
 ([fe80::46fb:96f2:7667:7ca5%5]) with mapi id 15.20.9052.019; Mon, 25 Aug 2025
 18:35:26 +0000
Message-ID: <d51c2e8f-70cb-4211-9196-be9021a33070@amd.com>
Date: Mon, 25 Aug 2025 20:35:21 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: your mail
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
 David Hildenbrand <david@redhat.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
 <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
 <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
 <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
Content-Language: en-US
From: =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
In-Reply-To: <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0322.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:eb::15) To PH7PR12MB5685.namprd12.prod.outlook.com
 (2603:10b6:510:13c::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5685:EE_|SJ1PR12MB6171:EE_
X-MS-Office365-Filtering-Correlation-Id: 6c20b062-d60d-4961-2dfd-08dde40628cd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?Qklpd2RzaWpmQm45bkRtdWM2NDVMZVZYSTl0eGFXbEs4UVNHWkc2Um9XUWhL?=
 =?utf-8?B?dWM4UEhicHJla0JXaktMYS9rR0UreUEyQ3JTUkRMNlpONVgvcjJYcGNqYUM2?=
 =?utf-8?B?VmEvQkJmUU05N1BQdUg4dnJLNmpMZUZBcFpSZDU5Uk1ZNjJPdkRocFhjbG90?=
 =?utf-8?B?YzZETjhCWG9jU25sOGxsYXU4bmZKNlRRY1JDMGdJVk1IYW5rTzhjMEZ5Y3Vq?=
 =?utf-8?B?M2F5Tk5aUm9lZU5pbVNLRHlISUk2YzBpVDdPUmc0Mi9FSEczWG94eEEwVlpG?=
 =?utf-8?B?V0lpZ0M2R2FyTjJ4WEMySkJZcG5BeEpkN1ZDeHBReXh0dnZKM2VWaU1OQThW?=
 =?utf-8?B?dkFJMEh3Mk5ZN0lhTWtSdnNHeTRjMktFdVNDMUVZM2crQkhEejFYSXBlR0hx?=
 =?utf-8?B?UitJaGJnejc0cFNJZThJaU9mZTQ5ajR4eWY0MzJvNXZJbmlUTHVzY285UDFt?=
 =?utf-8?B?cis5YWhoUFBTNWo5cFVpcmVoc1dTMWFObUFOSWNHbE5vd2M1ZlFYTjBQcFNZ?=
 =?utf-8?B?UGZBdTFxc1VrS2JwYkdjM0dma2txNFpFQXo4cDRoTFI4anVCblAxTzhHc1pG?=
 =?utf-8?B?ditVVnhlS2tJUWlqZ2VnVXlyM0JmRmxHQnNucXFJNkRrRDQyTnZjei9JdmRU?=
 =?utf-8?B?eDJKU3kvWkd5aENmUlNCVklQeHhwZEFqVmp0bVA1Z0Y2L1MzM0xCeUQwa1Fo?=
 =?utf-8?B?MXZ4UGpCYUI3RmVCbXVvZXIvVmxvcWx2Uk5xamR5MWhMRzdqdWlBS3NuSlhK?=
 =?utf-8?B?cG5jQTFWMXI1THR5cE01WlB5VVowQXM5dnp6cyttVlNTOFNxQ1pLMGp2cHh1?=
 =?utf-8?B?bkpWTlErdzdxbzQ2am5RWXRmUkwwbDZ2S2ZKQUM1bEhNVXBGcjVkczllMFNs?=
 =?utf-8?B?aHZKdk1ZOVpVYndINzhVd0tjK0MzMEliRE9QdUdybGljb1RVby9RMTBHUEFv?=
 =?utf-8?B?VlZpcGp6aUpxVWt2UlJGZGlEMTVlQVQ4ZUZxVW9YdWpIZ2lNWTZlZWVrdXk3?=
 =?utf-8?B?QS82KzcydlZxZHVBemtDNWIydEhTZTROYzFMaVFRRy9VbGQ1MFZZbmZhSzJo?=
 =?utf-8?B?VWdmaVlUSVpQWGVLOENFRGoxeFV6Y3R6SUh2SXUvNy9hY2hKc1VtYS90cDJx?=
 =?utf-8?B?dHo4WGFibzZNNEVwTFNHUWEwaVFoNFJJeTdaVmhVcFRZa2c4WmF4RkxJWmhx?=
 =?utf-8?B?bElDYzBDaENCdXgzS1E1Z1hZcE9QN0EwREtIRHQ3bHRadDd0TXBnVHUxeno2?=
 =?utf-8?B?cm5xTUNoY0dtakQ5NmxhVFhaUG1RT1BmcnlLbmF2NVhtWUxxd0NRSHNWOHdT?=
 =?utf-8?B?alBZK29DUHhaTUFxNUg1Q1ZCRDBYWGZ2TUY5QlFGMlNZQm5GVk5MeVZyWWdD?=
 =?utf-8?B?NzlhTzNGVmtjdWtpQ2RId2oxY20xV1RtSkNEV2pocDBrcUNyRjFOSFlpQm9J?=
 =?utf-8?B?SmlSRkVDRnFmcFlYVVZ1Ri9rbndYWDlkbnhyd1E4blRVeTFOK1NpeVNISDNM?=
 =?utf-8?B?Z2pLS3A3U1N6TkF2ZjM5Yk9DZmRvekVOb0Y0L0FZT2dOOUlGdnNMbC9VYWxC?=
 =?utf-8?B?U2IvYk54cXJUVjA1NE5Wb3pRSGZZREZiK1hQMlF4OURmT0Q1ZFlOeFdoOGZx?=
 =?utf-8?B?ZXdQU0p6Y2wwTmw0MnRKQmZDSXQrYVkxT0VyRThKSFhFUWFxdWdjOXphMk55?=
 =?utf-8?B?ZUo4d0FoTHdTa2FEa2MzaHVROG1rU0tSVW5HOEYwemNYcUx1TEJnT3JnZU5m?=
 =?utf-8?B?dVRaVGFGelRSTHpVeE5PWUd2cGxVdGIwWEF1dGQ1eWFnT0VzdnhzSUFZWjZ2?=
 =?utf-8?B?RWxhUThrQnlSZTZSZ2UvSmJkWE5ucFp1cCtUVHRodlNJSi9HbGpFYVF5Unhz?=
 =?utf-8?B?Z1RvOHpzZEp2bGV3VnI4cUFzRy9oNFltanptTkJxNWdpSjA0MUVxNXNJdzhh?=
 =?utf-8?Q?rOD2GIu89yQ=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:PH7PR12MB5685.namprd12.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230040)(1800799024)(7416014)(376014)(366016); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cjh3SnhRTThsSU93Y1c4S1FBVlBmbTkreTVmUXhhOW5IaVF4aDBwWWZlRGJB?=
 =?utf-8?B?UWV5Mnk3NTFTdGE2Mk92Ung5MFY2b2VPSnZsckZOYjJRa1JoSkVkOTd5QTdz?=
 =?utf-8?B?SGFvcEZ4ai9nWFFGUDF0ZHBCL1pIUVVSc1J0U2lwSnN1NmJZVmRZTkRWb3Nt?=
 =?utf-8?B?YmwvcVdGT1NZRy96cHRiL1FmdXhQMmo3MFRiSnVrNWxtNk8yNUZjNi95aFNE?=
 =?utf-8?B?cHdEanNsUlRZcGx6eVl3NHZxWU9yMkRaWnlnQ1BqcXd0TU9yL2hBeFNpU1Bo?=
 =?utf-8?B?V3E4UzcwZnRJSDhCdVp6bU5oQlNkTThMOXdQVEU3ZDFMSGRFU3kwTFNaRUF2?=
 =?utf-8?B?aVZiRG4ySU9sYkN2d21DSHhjYzBXWHlwZllHckd5akM2c2RVOGoyOXRqR1Fh?=
 =?utf-8?B?aFd6bTFsWE5BRFRkd3MyZWxWTTVZUnl3QVhEZ0FRa0s1OXQxbEpydWpIc1FP?=
 =?utf-8?B?ejhvWFFHMG9KMkFWN21WVVh4WUFQd2U3MXJBY1BUeWpobThnaUR2RGZld296?=
 =?utf-8?B?ejUybGFYOUNzMXFMb3ZlUjVkOG9XZFQ3ekFTcDJPdUlyaTZQb2VXd1M5VFNi?=
 =?utf-8?B?YTV1MFBKWXdKNTgvWjlMc0lqdXBiNFJudlNlS1ZVbGZpRm91Q0RlQWc0OGM1?=
 =?utf-8?B?cmI3TFBkcllKOC8zRllKRUE3cGtCS1lpRG02cE44c1BneERDU3hRcnh2Zmhm?=
 =?utf-8?B?V1MzeW1meHNRZUQ4NUJyYTFjWWN2WGhjK2REYmhhNys0bVpzZDc5bjFrMmpV?=
 =?utf-8?B?TDdGM2EyNDVINzJMTHlVY2dDOTZiUktJR2Vsd1ZUbGRMZDhqc0ZSUTI0Q2t2?=
 =?utf-8?B?RGVvTlBDbzNxaElxR1pzZ2lqNSsyUG04MDFrdVBocDEwa1U1NlQzUUk1L3NW?=
 =?utf-8?B?Y3dIdVlHV21nVjY3eTRHMS9rOVBmYlFhdWhhUEVGYmtrcHl4WVVTWXBTZEVr?=
 =?utf-8?B?aXBZTW5KVjBMNmt5N3lSTTVqWTRxUXd3dDBzbG4yU3gxdDZUMmVoUlY1a2Rv?=
 =?utf-8?B?ZXRkdDRrWHNIN1A2VFV6WjJIV3psQVhlU3hCYU13ZGxub1pMTlROR0xQbVh1?=
 =?utf-8?B?L0dlMjQ5UnA5OW1lbmFHbDFQdXJpRXZ5eFJERlFYNmtRWUVKUXJUbzV2VFBl?=
 =?utf-8?B?b3hOTHZoRG55VUttQlphNjRRalFrMGZsa0dGcTBhQThDUWtESXp5dWUyMGFq?=
 =?utf-8?B?QkFmNnVCTDhsVW5TblNIWkkzb2QrVG9oNlNMMFVIbktqWTV2eHZTNkh2V2Nt?=
 =?utf-8?B?UGdRWi9UZFE5aHBKd0tsR21HYlRwSHpYNHZ1QXJNT0t4c2U2WElKdUNJMlVZ?=
 =?utf-8?B?NVRqYldHUjdSczJCT2ZRc2RTWWFyZmRzd3lmaHRQdVBBVUJlbnFid1R6bjVH?=
 =?utf-8?B?enZQUzVzSXZZaEJ5TTErVG5zTXJQWnRVSy9XTzlwS2M1Vnk2NGN2VVIvQXZ2?=
 =?utf-8?B?aDhLbkxrQSthQTE1ekxPNTQrNHROZGxwY1dMdER1Z2RYZUpzYmtLQW1ra29W?=
 =?utf-8?B?MTVtWTZKY0FTQ1UxSG1SSmZlSTZ5RzByd2VrWm12TmthNEErOERMSVRsM0Uv?=
 =?utf-8?B?R0x0aERrQnVGQmRBNG9TZmo1eGcwU1p0RGNMODYwWHJVdXJ5Z25PNlVzMitH?=
 =?utf-8?B?MlR0Y2lweCt5VTA3SWl0VXQ4bitCbGdvS25LTEh2a1JxNG1GNkMxKzF2bmlq?=
 =?utf-8?B?S0paVldXK01jbG5OeG1ZM0xiZ2tIVU5veDlabjQxVStLTFRBY00wMkNpQmpJ?=
 =?utf-8?B?MW93eUpkNkVXb1g4bFhwKzBNaDF1eUVUc1psbjc3N2pxcENnanlOazU2R1l2?=
 =?utf-8?B?T2E5YnhYeTZuK0J3MTcwWFl5eWlpd0ZwUmY3U09IL1dwRFNYTGdncUlKZDYw?=
 =?utf-8?B?UmQxa0ZqS2JsZFo1cE12MW9MK25IaGhlN09ERGpPREwvVmoxSTJLekt3MTZn?=
 =?utf-8?B?d1BXRGk4bWlMdzF3SnM3TzR0TC9DY0NSaVZGc0JNc3hJVDhVSmlFaUlPYWNN?=
 =?utf-8?B?RFZCanJmSjZRK3pNSFc5TGZKelJZMG5KRmFNSDB0RFdERGxITGdmNWFmZHht?=
 =?utf-8?B?TDlNMEFTVThadUZPS0Z0VGpYY0VhVkNHUlU4d1BjTWVSUDcyUXo4QVBpMDJ2?=
 =?utf-8?Q?wxpwk4hwUtcMEkwVPjvGkVUnh?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c20b062-d60d-4961-2dfd-08dde40628cd
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5685.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2025 18:35:26.6096 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JsGu6s53zItGR/RJHKjyG8MKjsJcykrSLc97jFtQvOZQrdGNfULT9dnOkvDhAgi8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6171
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

On 21.08.25 12:05, Lorenzo Stoakes wrote:
> On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
>>> I will add this xen/apply_to_page_range() thing to my TODOs, which atm
>>> would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
>>>
>>
>> Busy today (want to reply to Christian) but
>>
>> a) Re: performance, we would want something like
>>    vmf_insert_pfns_prot(), similar to vm_insert_pages(), to bulk-insert
>>    multiple PFNs.

Yes, exactly that. Ideally something like an iterator/callback like interface.

I've seen at least four or five different representations of the PFNs in drivers.

>> b) Re: PAT, we'll have to figure out why PAT information is wrong here
>>    (was there no previous PAT reservation from the driver?), but IF we
>>    really have to override, we'd want a way to tell
>>    vmf_insert_pfn_prot() to force the selected caching mode.
>>

Well the difference between vmf_insert_pfn() and vmf_insert_pfn_prot() is that the driver actually want to specify the caching modes.

That this is overridden by the PAT even for pages which are not part of the linear mapping is really surprising.

As far as I can see there is no technical necessity for that. Even for pages in the linear mapping only a handful of x86 CPUs actually need that. See Intels i915 GPU driver for reference.

Intel has used that approach for ages and for AMD CPUs the only reference I could find where the kernel needs it are Athlons produced between 1996 and 2004.

Maybe we should disable the PAT on CPUs which actually don't need it?

> Ack, ok good that we have a feasible way forward.
> 
> FYI, spoke to Peter off-list and he mentioned he had a more general series
> to get rid of this kind of [ab]use of apply_to_page_range() (see [0]), I
> gather he hasn't the time to resurrect but perhaps one of us can at some
> point?
> 
> Perhaps we need a shorter term fix to _this_ issue (which involves not
> using this interface), and then follow it up with an adaptation of the
> below?

Sounds like a plan to me.

Regards,
Christian.

> 
> Cheers, Lorenzo
> 
> [0]:https://lore.kernel.org/all/20210412080012.357146277@infradead.org/
> 
> 
> 
>> --
>> Cheers
>>
>> David / dhildenb


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amd-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id DCD58CA0FE9
	for <amd-gfx@archiver.kernel.org>; Tue, 26 Aug 2025 07:49:34 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id 0B03110E5FD;
	Tue, 26 Aug 2025 07:49:34 +0000 (UTC)
Authentication-Results: gabe.freedesktop.org;
	dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="RK7h5QkT";
	dkim-atps=neutral
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by gabe.freedesktop.org (Postfix) with ESMTPS id C003F10E53C
 for <amd-gfx@lists.freedesktop.org>; Mon, 25 Aug 2025 19:20:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1756149625;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=z5OgTRxAaRTLrRHg2C4YU4ZWEhwhgTv8g6QHnboZ39Y=;
 b=RK7h5QkTQvFS9sL2tbhzUTXn2GLY3KD9zTpiol4377uO8p3LuH+SCISMOh8FX60+FdZ0ko
 p8jL2gkN4NqWpesPmDdr4q6GRDwyzfKF9xgwYjYf5PFM0ubl8WNwNdxnwvlpvrE5hHU+KX
 GP+bEnKmNME/fMnWm8idKBNZFQRAxfw=
Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com
 [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-472-pYtvO0rEOE-OENVEbjgorw-1; Mon, 25 Aug 2025 15:20:24 -0400
X-MC-Unique: pYtvO0rEOE-OENVEbjgorw-1
X-Mimecast-MFC-AGG-ID: pYtvO0rEOE-OENVEbjgorw_1756149623
Received: by mail-wr1-f70.google.com with SMTP id
 ffacd0b85a97d-3c6abcfd218so1932350f8f.3
 for <amd-gfx@lists.freedesktop.org>; Mon, 25 Aug 2025 12:20:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1756149623; x=1756754423;
 h=content-transfer-encoding:in-reply-to:autocrypt:content-language
 :from:references:cc:to:subject:user-agent:mime-version:date
 :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=z5OgTRxAaRTLrRHg2C4YU4ZWEhwhgTv8g6QHnboZ39Y=;
 b=AEF4K4VrVIks+FcdmDrmh1jA/QQcMpAqq9J9BW2LgbHtOdEKRr5Qdvj4x1p97dyxt4
 DleYPoqRmv7hzHCjLJSYg49Ch1IerthR19fKrbvX6bhXn5OA6v7AtuRCpfFfhtBb3mtK
 z8b6Bj+NUQDAB8bdNCxpWlhctfEL/MH5ASGXZDKCQSzn+jn5BZlefQx07eKygH1TMG23
 alYf2cs04fUO8zmjHDajno4hTNh6IX5lXafFA7gS6YQKjYiD3MUJHbQWIwe2v/GgL9zU
 zLclndnWL3pdUOW5bbdQ82qPHvIe5QZMtvRAFmS1rm86J8LDRYtCYxvKKIVPs5bauFr/
 adyw==
X-Forwarded-Encrypted: i=1;
 AJvYcCVkUUmjMu3p3Ga2ga3fvGUkJ1i2oTFXm4UYoa/0162fq9MukTXAvFlzcP677OhZgT65K7KAZf2H@lists.freedesktop.org
X-Gm-Message-State: AOJu0YyenU2kV5Kfu+E03hT9LKQS52b8a5V7jBVPafqtIbAkohn5XgHc
 9vFCfmcs0Q/B2aNs0w1tP+IYrm/zZ52cdzlN4XwzKsc9WkBKp8tXGYwexeVfZqpdEd8X4fT9xKJ
 iURC7+/e47V1DA6y4C+0zr2/5aDYTrm9qoeMxblxlkWzXdVZHKe9YF9R7qB8bEqjB7t0=
X-Gm-Gg: ASbGncuhJ4bFHDlrv67Rhk6rZ6oHmG8/xYaxAiroRP6bQ+cZudaXmSfcNuWhLJZdhcP
 51NYImzEPU+aTUPH0ZFYHGIXNbbYE4E+GNvjuuh/agMud67iBPdc80aEGB+TgQ1+r8PdqMYHqRu
 U72YwqdGHU31jFGivUB35U75M96V36BAVYnR0bCn5heGBJLxkvsuEZ1iDdee3Q6zCZ9LXyuZPlC
 r3TBHSoh5vVuQy9cxXSc+EC09Q+E6DQtWNN1QqD3i095UroASEGngCdnR+Uu4dXNPD475ogs57t
 shremyYo19SrCGEo3JDA6U83oOpf3eeezhrC9JVtuFFoUBJTuD6rDT5B9EeDkYrxDlJ2JF3/FRP
 aKjHQ7KHyyTTE70okvl3frqdyDoq/xWu22CMDKPw/SW+HBwGOQk/ILcMGfOLTXtJGn68=
X-Received: by 2002:a05:6000:40cb:b0:3c7:4062:5ba9 with SMTP id
 ffacd0b85a97d-3c740625e73mr6433948f8f.32.1756149623097; 
 Mon, 25 Aug 2025 12:20:23 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE5fLvW6GBrzoj0rwn7v+5ING7miK2XnhPDMAtGWy5ft9okjD6BcqLa6oMnevLNewMSeBM26A==
X-Received: by 2002:a05:6000:40cb:b0:3c7:4062:5ba9 with SMTP id
 ffacd0b85a97d-3c740625e73mr6433929f8f.32.1756149622598; 
 Mon, 25 Aug 2025 12:20:22 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f4f:1300:42f1:98e5:ddf8:3a76?
 (p200300d82f4f130042f198e5ddf83a76.dip0.t-ipconnect.de.
 [2003:d8:2f4f:1300:42f1:98e5:ddf8:3a76])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3c7116e1397sm12704676f8f.49.2025.08.25.12.20.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 25 Aug 2025 12:20:22 -0700 (PDT)
Message-ID: <a0888295-5f3a-48cc-9ca4-d7ba4d73f307@redhat.com>
Date: Mon, 25 Aug 2025 21:20:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: your mail
To: =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
 Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 x86@kernel.org, airlied@gmail.com, thomas.hellstrom@linux.intel.com,
 matthew.brost@intel.com, dave.hansen@linux.intel.com, luto@kernel.org,
 peterz@infradead.org, Liam Howlett <liam.howlett@oracle.com>
References: <20250820143739.3422-1-christian.koenig@amd.com>
 <edf4aee5-54eb-4fad-aa89-4913d44371fe@redhat.com>
 <7db27720-8cfd-457c-8133-5a7a1094004c@lucifer.local>
 <82e5e566-87e9-43a8-a0e9-00656572d65c@redhat.com>
 <f6f85c73-2a1e-438a-82c9-f3392d91020c@lucifer.local>
 <d51c2e8f-70cb-4211-9196-be9021a33070@amd.com>
From: David Hildenbrand <david@redhat.com>
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <d51c2e8f-70cb-4211-9196-be9021a33070@amd.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: _RdtvPnb74T3Q6uFNvJs_9830iSr7t91VMyIRUwyw1c_1756149623
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 26 Aug 2025 07:49:33 +0000
X-BeenThere: amd-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for AMD gfx <amd-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/amd-gfx>
List-Post: <mailto:amd-gfx@lists.freedesktop.org>
List-Help: <mailto:amd-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>,
 <mailto:amd-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: amd-gfx-bounces@lists.freedesktop.org
Sender: "amd-gfx" <amd-gfx-bounces@lists.freedesktop.org>

On 25.08.25 20:35, Christian KĂśnig wrote:
> On 21.08.25 12:05, Lorenzo Stoakes wrote:
>> On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
>>>> I will add this xen/apply_to_page_range() thing to my TODOs, which atm
>>>> would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
>>>>
>>>
>>> Busy today (want to reply to Christian) but
>>>
>>> a) Re: performance, we would want something like
>>>     vmf_insert_pfns_prot(), similar to vm_insert_pages(), to bulk-insert
>>>     multiple PFNs.
> 
> Yes, exactly that. Ideally something like an iterator/callback like interface.
> 
> I've seen at least four or five different representations of the PFNs in drivers.
> 
>>> b) Re: PAT, we'll have to figure out why PAT information is wrong here
>>>     (was there no previous PAT reservation from the driver?), but IF we
>>>     really have to override, we'd want a way to tell
>>>     vmf_insert_pfn_prot() to force the selected caching mode.
>>>
> 
> Well the difference between vmf_insert_pfn() and vmf_insert_pfn_prot() is that the driver actually want to specify the caching modes.

Yes, it's all a mess. x86/PAT doesn't want inconsistencies, so it 
expects that a previous reservation would make sure that that caching 
mode is actually valid.

> 
> That this is overridden by the PAT even for pages which are not part of the linear mapping is really surprising.

Yes, IIUC, it expects an earlier reservation on PAT systems.

> 
> As far as I can see there is no technical necessity for that. Even for pages in the linear mapping only a handful of x86 CPUs actually need that. See Intels i915 GPU driver for reference.
> 
> Intel has used that approach for ages and for AMD CPUs the only reference I could find where the kernel needs it are Athlons produced between 1996 and 2004.
> 
> Maybe we should disable the PAT on CPUs which actually don't need it?

Not sure if that will solve our problems on systems that need it because 
of some devices.

I guess the problem of pfnmap_setup_cachemode_pfn() is that there is no 
interface to undo it: pfnmap_track() is pared with pfnmap_untrack() such 
that it can simply do/undo the reservation itself.

That's why pfnmap_setup_cachemode_pfn() leaves it up to the caller that 
a reservation was trigger earlier differently -- which can properly be 
undone.

-- 
Cheers

David / dhildenb


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org>
Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33])
 by casper.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux))
 id 1gHOe2-0005ht-WB
 for barebox@lists.infradead.org; Tue, 30 Oct 2018 07:41:00 +0000
Date: Tue, 30 Oct 2018 08:39:35 +0100
From: Sascha Hauer <s.hauer@pengutronix.de>
Message-ID: <20181030073934.ozmp24vip5jt4h44@pengutronix.de>
References: <CAEp+FuBh4S3a_yHmzegNCFDXqMDYjhpAMaWwWAE6zpfC9R0ERA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEp+FuBh4S3a_yHmzegNCFDXqMDYjhpAMaWwWAE6zpfC9R0ERA@mail.gmail.com>
List-Id: <barebox.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/barebox>,
 <mailto:barebox-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/barebox/>
List-Post: <mailto:barebox@lists.infradead.org>
List-Help: <mailto:barebox-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/barebox>,
 <mailto:barebox-request@lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "barebox" <barebox-bounces@lists.infradead.org>
Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org
Subject: Re: your mail
To: Mihaita Ivascu <mihaita_ivascu@trimble.com>
Cc: barebox@lists.infradead.org

Hi,

On Mon, Oct 29, 2018 at 06:53:55PM +0100, Mihaita Ivascu wrote:
> Hello,
> 
>      I am working with barebox 2018.04 version. I would like to create
> a script file that can be present initially in the new barebox image
> and then modified and saved by users.

You can put it to defaultenv/defaultenv-2-base/ in the barebox source
tree. It should be available in /env then later.

The barebox source tree contains a tool to read/write the environment
from Linux later.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Subject: Re: your mail
Date: Mon, 15 Feb 2010 16:35:31 -0800
Message-ID: <20100216003531.GL3714@count0.beaverton.ibm.com>
References: <1266274696-23018-1-git-send-email-serue@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <1266274696-23018-1-git-send-email-serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
List-Unsubscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linux-foundation.org/pipermail/containers>
List-Post: <mailto:containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: Serge Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
List-Id: containers.vger.kernel.org

On Mon, Feb 15, 2010 at 04:58:13PM -0600, Serge Hallyn wrote:
> We've currently got ns_exec both in user-cr and cr_tests.  Let's
> give the user-cr version all features of the cr_tests one, and
> get rid of the cr_tests one.
> 
> I'm also renaming it nsexec bc nsexecwp is stupid and ns_exec is
> annoying, whereas nsexec lets you type 'nse<tab>'.

For the series:

Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Cheers,
	-Matt Helsley

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: your mail
Date: Tue, 16 Feb 2010 11:04:25 -0800
Message-ID: <20100216190425.GA23298@us.ibm.com>
References: <1266274696-23018-1-git-send-email-serue@us.ibm.com>
	<20100216003531.GL3714@count0.beaverton.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <20100216003531.GL3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
List-Unsubscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linux-foundation.org/pipermail/containers>
List-Post: <mailto:containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
List-Id: containers.vger.kernel.org

Matt Helsley [matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org] wrote:
| On Mon, Feb 15, 2010 at 04:58:13PM -0600, Serge Hallyn wrote:
| > We've currently got ns_exec both in user-cr and cr_tests.  Let's
| > give the user-cr version all features of the cr_tests one, and
| > get rid of the cr_tests one.
| > 
| > I'm also renaming it nsexec bc nsexecwp is stupid and ns_exec is
| > annoying, whereas nsexec lets you type 'nse<tab>'.

To further simplify typing, how about having nsexec clone() all namespaces
by default ? Or maybe with "-a" option ?

But this patch set looks good.

| 
| For the series:
| 
| Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
| 
| Cheers,
| 	-Matt Helsley
| _______________________________________________
| Containers mailing list
| Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
| https://lists.linux-foundation.org/mailman/listinfo/containers

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alasdair G Kergon <agk@redhat.com>
Subject: Re: your mail
Date: Thu, 20 Oct 2011 01:57:25 +0100
Message-ID: <20111020005725.GV24527@agk-dp.fab.redhat.com>
References: <Pine.LNX.4.64.1110192014570.24440@hs20-bc2-1.build.redhat.com>
Reply-To: device-mapper development <dm-devel@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dm-devel-bounces@redhat.com>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.1110192014570.24440@hs20-bc2-1.build.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/dm-devel>
List-Post: <mailto:dm-devel@redhat.com>
List-Help: <mailto:dm-devel-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=subscribe>
Sender: dm-devel-bounces@redhat.com
Errors-To: dm-devel-bounces@redhat.com
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com, thornber@redhat.com
List-Id: dm-devel.ids

On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> The next one adds a conditional resched (Alasdair 
> agreed on it --- it should be later put into general Linux headers).
 
Indeed, this part:

> +#ifdef CONFIG_PREEMPT_VOLUNTARY
> +#define dm_bufio_cond_resched()                	\
> +do {						\
> +	if (unlikely(need_resched()))		\
> +		_cond_resched();		\
> +} while (0)
> +#else
> +#define dm_bufio_cond_resched()                do { } while (0)
> +#endif

doesn't really belong in a dm file.

Alasdair

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joe Thornber <thornber@redhat.com>
Subject: Re: your mail
Date: Thu, 20 Oct 2011 10:52:15 +0100
Message-ID: <20111020095214.GA4680@ubuntu>
References: <Pine.LNX.4.64.1110192014570.24440@hs20-bc2-1.build.redhat.com>
Reply-To: device-mapper development <dm-devel@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dm-devel-bounces@redhat.com>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.1110192014570.24440@hs20-bc2-1.build.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/dm-devel>
List-Post: <mailto:dm-devel@redhat.com>
List-Help: <mailto:dm-devel-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=subscribe>
Sender: dm-devel-bounces@redhat.com
Errors-To: dm-devel-bounces@redhat.com
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com, "Alasdair G. Kergon" <agk@redhat.com>
List-Id: dm-devel.ids

On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> Hi
> 
> Here I'm sending two dm-bufio patches. The first one fixed 
> dm_bufio_release_move function (the write callback could be called with a 
> wrong block number). The next one adds a conditional resched (Alasdair 
> agreed on it --- it should be later put into general Linux headers).

Thanks Mikulas, merging now.

- Joe

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <intel-gfx-bounces@lists.freedesktop.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id 35A82C71157
	for <intel-gfx@archiver.kernel.org>; Wed, 18 Jun 2025 13:06:27 +0000 (UTC)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id CC3A610E81F;
	Wed, 18 Jun 2025 13:06:26 +0000 (UTC)
Authentication-Results: gabe.freedesktop.org;
	dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="DmrIaI5x";
	dkim-atps=neutral
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13])
 by gabe.freedesktop.org (Postfix) with ESMTPS id A661510E81F
 for <intel-gfx@lists.freedesktop.org>; Wed, 18 Jun 2025 13:06:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
 t=1750251986; x=1781787986;
 h=date:from:to:subject:message-id:references:in-reply-to:
 mime-version; bh=CoE8Gd/r5125FR0HS/Oammnv6D60apZR2lNS6M1ejgw=;
 b=DmrIaI5x53V8e7Z7K9oa6rpy+6/5SqaVCE+sqRJ1kqbx0QbFlBDKhLqZ
 6VRAJgHnvYu9BGHLMTPxQy/A4HxTpdMC61b8davHH8dWjwtVWXkpLegsk
 wmBqg+Z8MXAx1JQc/Syz3qHnm/b8PW+t3MvXB29MPEVTcf9dSirCSoClC
 pk+CiTyy7TakFwPeYJwjzbkGkvMDH1xunYf5GmCKe860CWAycptgysCa7
 0jo6DbxFKBsipZLQWEMTpZeS0+foJH5G5qAZAYw/UVTAsBBpOF/701szs
 dKtvcwFleP3qpzzdvV4jMM0lqxl2QKPXo5uDVDKOgDirIRBp+0Gk7w9Jw w==;
X-CSE-ConnectionGUID: RSwdbaEqQ+mlnkVzptgMuA==
X-CSE-MsgGUID: FgqbkbjORQuEZq6uWfFr5A==
X-IronPort-AV: E=McAfee;i="6800,10657,11468"; a="55086138"
X-IronPort-AV: E=Sophos;i="6.16,246,1744095600"; d="scan'208";a="55086138"
Received: from orviesa007.jf.intel.com ([10.64.159.147])
 by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 18 Jun 2025 06:06:25 -0700
X-CSE-ConnectionGUID: U5F8DXUQTDG4+yNzsfxELQ==
X-CSE-MsgGUID: fOLeNornTSuCBWyRtkLIcg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.16,246,1744095600"; d="scan'208";a="150071917"
Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24])
 by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 18 Jun 2025 06:06:25 -0700
Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.1544.25; Wed, 18 Jun 2025 06:06:24 -0700
Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.1544.25 via Frontend Transport; Wed, 18 Jun 2025 06:06:24 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (40.107.92.82) by
 edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.1544.25; Wed, 18 Jun 2025 06:06:21 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=D7mYNow6Lv0W4b2B8y4Aoqqmji3Gm87ZgnBIFNr2ZcJV8mh6Ug6d61qyyYbObJlw73okvrb+9u4dfWnRtwYng9GGRd6Gvy/2UR9k+VlO/RyS5zfrui+f8VTX2z6+1ApyuoLdX/0xPgxIqV0khqIv0Jkvs5PLjMYurHhumBFWrOtC6IJuidoifhxFGYURNI57kRa2mrG3lI06bWN3D3BKCxGgS1n7MwTo11RxIJcrfrqthw+rLU4ZYNXj+G96+W7CzfbjOtVl6oHCnud4cKycdVNR3er+fw84OVROC/nixeGlVPSTXGBlAFVDFxI9AxRHYSE+NuMqUhuv+RStIast4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CoE8Gd/r5125FR0HS/Oammnv6D60apZR2lNS6M1ejgw=;
 b=J/2yZLUGNOXxe0Gw7kuav1YDz8laSxG35dDP4i2J/ziBRT/Wgz+PGZkxSTDJj1x3iUvMZFyYyTebgB7CXzbxn6OKMSySVx1EbZO17qkiCpx3QnjwP5LGvceBVOS+KSqOxEnWuMEu27Z0TdLTnfQUs54dT8oToiJ2EXV6BEEEajGimfl3XFCcB4rDkmaS+cqrwjrUeNMtcZGgNR9+4MJZY9OkmNgqIiRRgK0dwhQ70JaHwlz8q0z5ZHkbqk3i8faXTT6TnESUOQJWMqg71YMxKVmpbT0QdMIbrs3KsaRiSor8V26h29qfGsRgzm2xexnk2MIde2dop6HoF3W/jjFKIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Received: from CO1PR11MB5057.namprd11.prod.outlook.com (2603:10b6:303:6c::15)
 by SA1PR11MB8594.namprd11.prod.outlook.com (2603:10b6:806:3b1::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Wed, 18 Jun
 2025 13:06:06 +0000
Received: from CO1PR11MB5057.namprd11.prod.outlook.com
 ([fe80::3b75:a8d2:464e:30cc]) by CO1PR11MB5057.namprd11.prod.outlook.com
 ([fe80::3b75:a8d2:464e:30cc%4]) with mapi id 15.20.8857.019; Wed, 18 Jun 2025
 13:06:05 +0000
Date: Wed, 18 Jun 2025 13:05:57 +0000
From: Krzysztof Karas <krzysztof.karas@intel.com>
To: <intel-gfx@lists.freedesktop.org>
Subject: Re: your mail
Message-ID: <jgr44hpf6ardaunhh3tr4pvcqcv7kvdljh2m5idr5c3quhjq5w@x5eyznstuuuu>
"Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173,
 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316"
References: <enmvs5xc2vjomnhaumdpt6ygv3berd7acuz2usz5hvprgey3x2@6bepnus3ve52>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <enmvs5xc2vjomnhaumdpt6ygv3berd7acuz2usz5hvprgey3x2@6bepnus3ve52>
X-ClientProxiedBy: VI1PR0902CA0029.eurprd09.prod.outlook.com
 (2603:10a6:802:1::18) To CO1PR11MB5057.namprd11.prod.outlook.com
 (2603:10b6:303:6c::15)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PR11MB5057:EE_|SA1PR11MB8594:EE_
X-MS-Office365-Filtering-Correlation-Id: dcb03cec-8c8d-48c7-1baa-08ddae68e296
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?Wk1DRDlJMURyR2xqczdiQ2hFSnB4dlNPSTM4M1BkSkRhZnBoY1grSG9qdjRJ?=
 =?utf-8?B?QU1qU0lzb3lEay9vNGVQcFhQeVdGVzVNNm85Z2FuK2JXOXFCUFhWL21YMnlR?=
 =?utf-8?B?RW85dnJadldiYlhUQXJQdDhnbXZnOHZRbVYrYzlzQmRZaUVreTNoWHBaSFNH?=
 =?utf-8?B?R2RxdmZBeHJRYkkwbitzWDJ4cmpOUjVQNGN6N2Y3ZjQ3UWNEeGlyOUNkOXp2?=
 =?utf-8?B?WGUyeGhBRnBER0lQbkRta0pmcDMzU3hYR2hjYm5XdnZmR0hZTjhzNkZPWXZn?=
 =?utf-8?B?U0ZQdERjZWhEakgvK3pzS2Q1TjJIdTd6ODVQMlQ4emhYRjV0NXR0UWtVeXc0?=
 =?utf-8?B?RnQxcWlvaitmTTBOQy9Sck9zVFlxUnI3aG5lVUFKVEUxVERrUVhjRmg4NTBm?=
 =?utf-8?B?TUYyRFVROWU2L0hQdXR5REFEUnI5SkxldXBId1Y5WHNLY2NrdmJ4V3VVN3c3?=
 =?utf-8?B?ayt5NjU4YUFzbnhuNDdVQnRSeDM5QnpRbEx1NVptRytNKzFTTUpZZnAxUjNX?=
 =?utf-8?B?Y2FPQVFIMjUyb09wQ3pSSWRTWTRhMm5IQXVuRUpscTdObElNZDNhRjd4TlU4?=
 =?utf-8?B?aVhoNEtaYmFQeTQwak5pQnc2SmNWYUI5Q1ZkTzBXT1B5OWg3amliamZ4Q3o2?=
 =?utf-8?B?VUFxZ2piY010NlZFR3FMR293YTdEZnB3eHEzZE90MGMraEFVZGtvcC9jYUZq?=
 =?utf-8?B?RTBrWENXRm1XN21pRERRb2hrZFAzSTVRUUp6OWlGclZESHgzL1VLSklaS2Rq?=
 =?utf-8?B?amYvRFVNUHhwaGRPbXV6dll3WkN3ZVNZYkQrZldBTjRibzVtM3ViMWVzQ0k1?=
 =?utf-8?B?dDdQNDdZNDMvODdWTGROc0ZpNnRhQlhVRkpMVzBtNFFPZ0VIVG1tTDVzMmxt?=
 =?utf-8?B?Wjhxb0lvckhqbzdOSEQrcUx5U2hhcnVLMXVBT1lSVjAwUFdUT3NveUF2ZDln?=
 =?utf-8?B?UUxzc0pEWXFqcjE5Y1ZuMjBETTJqU0RwMGRRSWs2cjdPMFN2U1hEQURpZ044?=
 =?utf-8?B?ZUtsd21JRE4yM1lkb3RJOFFzYVNWM0RLS2dlR3h2UHk3US9hOVhTN1JpUmlD?=
 =?utf-8?B?UEl1VjF4R2VGV2d4MXBKR0VIbitZZG9CM3kxRDlNK3hUZ2tCdEhnMTJaY0t1?=
 =?utf-8?B?MmlBVlY0aXRxRHJBWUVzQTNCc0JDaE5hcFV1WWV4YUNGM2ZuTytOZ0hLMC9H?=
 =?utf-8?B?bUJCaUt2cE5jQURydVpnWXM4Qk16WkhkeGRoMjRqNFVMWFdqeVdndkpvYUUy?=
 =?utf-8?B?Q3VpOWtpb2F5NmppRjM4OThQUDZHaU9jV3c3bVVGRUJFQUU1YXl3THlWYy9I?=
 =?utf-8?B?K0dXdzRMUWEyU0s3dTZ3dzJESGNvU1hQRlN5VGVZbG1CcW8rRUxDZnVPMlpS?=
 =?utf-8?B?OXRPN2pDSVlwMVY3YStmYW5kMG5NNkV2cElsQkQ3M3FLTmpBd1BvUG5kYm1m?=
 =?utf-8?B?Um1acnJza2NYeEdBOGp5QThyalpsd0VqUTZmUkpwZjhCWWpOWjBCNStwUi92?=
 =?utf-8?B?UmRTMDVHc3krKzlnVVB2aUdPd3BiMnJOUkhyNmNRYVM4UFlMdTlBbjdYRGRB?=
 =?utf-8?B?UFZkY1k4bEJQR1NPYUc5cWhEbi9SUHZJZ3A3WlE0Tzh4UjZ4UjJFVGRGTXQ4?=
 =?utf-8?B?bXBjUDAyTFpEb2hMdURLYnMzL3NYN1JscHVIaUlwVUZJQUY5M1NhZlBvVERv?=
 =?utf-8?B?OVhtVXhYZEgxdDkwVE5qdUplVUplZ0NnbXpMNnU2NVR6V3QvVDdRSTNyZDdi?=
 =?utf-8?B?SXVObjkyM2tPeGRyeWg0U09SajdHQTB3amJJeDMvSkdMSFF0M0czVDg3aHNS?=
 =?utf-8?B?QkhJSGRwYk5VdExvMXVuWU1pckdEL2ViL3BJSDVoUG9OcnNxeXNwMDNad3dV?=
 =?utf-8?B?blgrNE1pSWJmV2pXam1QZjNkZm5Pcnd6UlRGQ0U1Z3NWbEZsMTZsYXIvRzE4?=
 =?utf-8?Q?CCJJgUYGv9U=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:CO1PR11MB5057.namprd11.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230040)(366016)(1800799024)(376014); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VFJoSGwxZGcranhGMTBqQkVpUGlJRjdKTXU1UXpac0J6TmFEamt5cHljQmFP?=
 =?utf-8?B?WGZ3ejRTWUlLUnJjL0tPMzFyWmpwZTUwUm5ScjQrTnRGT0JiTDgzTll2eW16?=
 =?utf-8?B?a1Bmc1N2amdvQkY2cGJ5aTFMZTNUNGQwMmlqcExyYlRoVzRvVStvSlBTUmho?=
 =?utf-8?B?Z3NsaTZETXBZRjZkcWROMVF6ZXBhUHlqcForeENqaVJNb0YvTTdjckJ5SExT?=
 =?utf-8?B?cmdPRmVLZHRNeGlwOGkxR3pPaTk5RUZpQTlGTUxDMng0RW1IRGRBZ081Lzlo?=
 =?utf-8?B?R1dnZ0RYT3pNYjh0ZHRMMXRXc1psUHVmcGs4c3FmRlFRNy9wVld1cUh5QW5D?=
 =?utf-8?B?OG1ZOFNZZ0dNMU1kanFoNTczRHVHWW9aOGV6ZDl5UnZYdzdiekNwZHJNdStX?=
 =?utf-8?B?QURSNkI4Z3lUQ0wxZVBvY2J1ZFVKMVAwd2l0R1diMmsrR2k2R1hsNm5yQTA1?=
 =?utf-8?B?cEpLWTZNOGlXc3hxb05jWWsveGpYNi9UWUtzSDBOaG9kNGViM3JhWXdjZFFo?=
 =?utf-8?B?UExmS3VQK2pxcnI4VkoxcXA2M1Q1OS9hOGFIMi83WjVROGhyKzFyN0VhQ3lO?=
 =?utf-8?B?RXBJWHQ0a1JnUmVCSXMzSG94OU5vSldvQ0dQVVpON2w1LytRbEVkOVJMZXVq?=
 =?utf-8?B?SHV1MUcxVkRxR011dHNVNlFIa0pVdlRkTUtKQ2VsbDdhbnAyZkhITjhXYktL?=
 =?utf-8?B?RHV6c3dyQW9BZjlISUt1YUJPN3JvUDhCNEhZanFRTzlnck5WZG1KT0NXdXdr?=
 =?utf-8?B?d1VmLzlSVXdFQTNsVWFiVzJrdHhmTkVPTnh4UlFpc1dkOUJBUVRWNXZEWDlW?=
 =?utf-8?B?K2JYeEw0TmNSc2VTUnFoL2MrSVpIQ1oxZWVsRU1vUXp0cU1rSUgvdG5wQ2xO?=
 =?utf-8?B?ZDFJV01qOFZ5cTdvM2VCOVd0aC9JcTlGQkZ4dm1mMEI0WjYva0NBdnZLWStl?=
 =?utf-8?B?bDBFMGQwazIydVQ1VFR2QTV6bUg0c0o0Q0ZiaEhaZlR3bm9HOWo3cElnditm?=
 =?utf-8?B?UUFmT2Mrc0VXN3JETFBNcFlHUnQ2MW15SWt3SG9LaFdLaUxhVFZwS2lkcFpE?=
 =?utf-8?B?S1hBRUlERXJqd3poK3V4cUVFSzd5T1Z6aGd4U0x4eEluSnU2QnhzRUpqWUZ0?=
 =?utf-8?B?MUFYbFFzbUt3ak1Qc2RLRkxRazkzeUZtZzgxUDJGUmFqSExTT2ZyMUN5T3pD?=
 =?utf-8?B?Z2I4dmtNQjc5ZWtncGR6b3pub2VNcjdoVjV4WndPdFFqci9XRWd6REkvS2M4?=
 =?utf-8?B?aTd3cG5OcGhrdHkxaGQvSWNRdDluQ1VyOUZkK0svM3JUSUw2TVFRa3VHK29h?=
 =?utf-8?B?QTlEbVpIa2N1TWxWZnpONk05dVlyQjl1enFUUGpYd2JzKzVsT3hwejBHL0Z1?=
 =?utf-8?B?M0VsN0tlMUh5T1BXM0E2WmlGNjZwbG1kODhoTXN5SVR3MzNKUzE1VVJUdmNk?=
 =?utf-8?B?SnZtWUNvTnhyTzYxUitOMzFTOTRkWGZmSGNiOERLdkJGMWMzUFR6UHVWd2FK?=
 =?utf-8?B?NW56WXdvY3NLUWh0K2llVlZLTzY2OVJKRjB3MzlMMFBnNGc5NEE0Z00vaHR1?=
 =?utf-8?B?RkhvMDQ5bzJZMnNEcDRrazJxN1FCOUs5dllldC84V0hGeThiZzdMdzNqUjJv?=
 =?utf-8?B?WURleEVnL1ppTyt1WnF5WUhlY2d2Q1Voc3lWMXRvTHZuS2JoTk1Eb1NrSDFY?=
 =?utf-8?B?aFVZeFpLN0NBdktiWnBqY1lkc3dibXJFNWUyL2dSZCtHd2xLYTZjaEhSdHdn?=
 =?utf-8?B?TFhSdDE2dm51c1NwRWxnZEVVTEpFaGZBSnRxK1BkRzRjWnMwTVRiUWZud3ly?=
 =?utf-8?B?Q2VFRE5lRmdrdFRLWW5TY2VFKzByK3NGODdkdUpTUllBMDRzOFBTTWk0Umk1?=
 =?utf-8?B?TTJtc1dDWndTdzhkNmY4cDdVMXFobldaaW4za0NrRyt2M1lSWDN0WGdIbmFF?=
 =?utf-8?B?WGhBMjB3TjBmQ09VeUR0SWpKUi95SW04THZFb0xsQWJRNHM1MmpmTEhoUjBn?=
 =?utf-8?B?NHh3eXJ3VGNla1haUnpJdkNORnA4eUM5QzR3NkNjK2RHT3UwWTRXMnlBYXhU?=
 =?utf-8?B?Z0hOMWFobmZQeTJFazQ0SFF2eFZKVmFKYm1yV0ZUWCtOK2VFU0dUVG1CWk56?=
 =?utf-8?B?QWZXaTk5RDlKZlEzaW8vZVp4a09QUDVLbFlIamwyRUFDTy9oeXVsdGhEYUV3?=
 =?utf-8?B?dEE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dcb03cec-8c8d-48c7-1baa-08ddae68e296
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5057.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2025 13:06:05.9013 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IZlnS7SUXY8GWGS2QZL++9DGjX1mDsnpoFQ2Ii8iFSiAzflJ9cI/jMcteGMjTBS60+1oLTsloNs+6wgQDyLJVAbaLorpO53Q1kxSecYI57k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8594
X-OriginatorOrg: intel.com
X-BeenThere: intel-gfx@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Intel graphics driver community testing & development
 <intel-gfx.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>

Please disregard this email, I made a mistake while sending
a bunch of patches. Sorry for the noise.

---
Best Regards,
Krzysztof

From mboxrd@z Thu Jan  1 00:00:00 1970
From: walter harms <wharms@bfs.de>
Date: Thu, 18 Oct 2012 15:47:38 +0000
Subject: Re: your mail
Message-Id: <5080249A.5090000@bfs.de>
List-Id: <kernel-janitors.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: kernel-janitors@vger.kernel.org



Am 18.10.2012 15:17, schrieb Nicolas Palix:
> Hi,
> 
> 
>> But I do think we should maybe find another list for Fengguang's
>> emails?  It's sort of a lot higher traffic than before and sort of a
>> different flavour.
>>
>> I still will want to subscribe to the emails, but it would be better
>> to use a different list.  Apparently Dave Miller didn't like the
>> idea of creating a special list for it because he didn't like the
>> emails in the first place.  But now I think everyone likes them a
>> lot.  It might be worth asking again.
> 
> I agreed in the first place but kernel-janitors is also a great place
> for newcomers.
> Having those reports accessible could be great for them. Also, it is not
> that different than the janitorial work done before. The main difference I see
> is that there is no fixing patches associated to the reports. But the problems
> addressed are almost the same, and they are found with the same tools.
> 
> Does it worth a new list ?
> 
> Maybe the set of branches tested need to be further refined to lower
> the false positives.
> Finally, we may hope developers will test their patches before releasing them.
> 
> Is there any mean for them to apply the tests before pushing ?
> 
> If a new list is created, please let us know how to subscribe to it on this one.
> 
> Regards.
> 


I support the idea of a new list. The reports are mostly nothing that what the janitors can
review. Fengguang is important but cleary targeted to developers in ongoing projects.
Janitors care more about the state of the current kernel.

just my two cents,
 wh



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Igor Filakhtov <filakhtov@gmail.com>
Date: Tue, 03 Sep 2013 14:02:55 +0000
Subject: Re: your mail
Message-Id: <CALKTHW1LYjtEyrJrSQvV__YPn_uwWHjGZfEjXThTFhVDJHC-Rg@mail.gmail.com>
List-Id: <lartc.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: lartc@vger.kernel.org

I have a total control over IP adresses, static DHCP and so on, so
this is not a problem.

Best regards, Igor V. Filakhtov

GMail: filakhtov@gmail.com | Cell: (050) 65-66-280 | Skype: ihor.filakhtov


On Tue, Sep 3, 2013 at 12:11 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 30/08/13, Igor Filakhtov wrote:
>> Greetings all,
>
>> There are 5 users in my LAN, every of those have at least two devices
>> (pc, smartphone). These devices using static DHCP addresses. All
>> packets from single device owner are marked.
>> These packets later are shaped using TC.
>
> It might be easier to filter the traffic with tc (match ip
> src/dst/sport/dport) instead of relying on iptables.
>
> --
> Nicolas Sebrecht

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konstantin Boldyshev <konst@linuxassembly.org>
Subject: Re: your mail
Date: Wed, 9 Oct 2002 22:04:32 +0400 (MSD)
Sender: linux-assembly-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.43L.0210092152320.1778-100000@alpha.linuxassembly.org>
References: <F129z5Bl8LgFuoe5ciz00000d57@hotmail.com>
Mime-Version: 1.0
Return-path: <linux-assembly-owner@vger.kernel.org>
In-Reply-To: <F129z5Bl8LgFuoe5ciz00000d57@hotmail.com>
List-Id: <linux-assembly.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Joshua Hudson <joshudson@hotmail.com>
Cc: linux-assembly@vger.kernel.org, konst@ipian.kazan.ru

On Wed, 9 Oct 2002, Joshua Hudson wrote:

> When hunting down the last errors remaining in tar, I came across
> a particularly weird one in both tar and chmod.
>
> Try chmod 4755 true. True will have mode 755.
> This happens in linux 2.0.63, 2.2.22, 2.4.18-3
> Is anybody else getting this? Anybody have a solution?

It is chmod bug, it did 'mul bl' instead of mul bx.
CVS version has this bug fixed.

-- 
Regards,
Konstantin



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: your mail
Date: Sun, 3 Aug 2003 11:30:50 -0700 (PDT)
Sender: linux-assembly-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.44.0308031123030.31440-100000@home.osdl.org>
References: <200308031136.17768.lx@lxhp.in-berlin.de>
Mime-Version: 1.0
Return-path: <linux-assembly-owner@vger.kernel.org>
In-Reply-To: <200308031136.17768.lx@lxhp.in-berlin.de>
List-Id: <linux-assembly.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: hp <lx@lxhp.in-berlin.de>
Cc: linux-assembly@vger.kernel.org, Kernel Mailing List <linux-kernel@vger.kernel.org>, "David S. Miller" <davem@redhat.com>


On Sun, 3 Aug 2003, hp wrote:
>
> so He/You did lock me out, too?
> whithout any notice. by what reason?

Maybe because this has nothing to do with the kernel?

It's ok to discuss kernel issues on the kernel mailing list, but we've had 
tons of totally off-topic flames, rants and general noise.

To the point that a lot of people don't even have time to follow 
linux-kernel any more, since a lot of the discussion has nothing to do 
with the technical kernel work.

Since some of these rants are started (and kept going) by people who don't
ever seem to actually get involved in _real_ kernel-related technical
discussions, David felt that one way to curb it was to just blacklist 
people who repeatedly post things that aren't related to the kernel.

It's ok to be off-topic every once in a while, but it's not ok to 
consistently be so.

That said, David is also not the most politic person I know, and I suspect 
this could have been handled slightly more gracefully. One potential less 
annoying approach is to not block posting from people, but rewrite the 
subject line for such posters with a prepended "[OFF-TOPIC]", and just let 
people filter those out on the receiving end. Or just automatically shunt 
them off to another list.

I dunno. I don't personally much care - but I've never been the maintainer 
of the mailing list, and I sure as hell don't ever want to be. Whoever is 
the maintainer gets to set the rules.

			Linus


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0D422F23
	for <keys@linux.kernel.org>; Thu,  3 Feb 2022 14:18:57 +0000 (UTC)
Received: by mail-qk1-f169.google.com with SMTP id c189so2644530qkg.11
        for <keys@linux.kernel.org>; Thu, 03 Feb 2022 06:18:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linuxfoundation.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=eSZEZ+s5jm/XWtSJuIpYfB8Rxp013Rv0vhhbXCPzESs=;
        b=MwOM4T6wrVoerlSgOGgireFnJ8emw1gFareVQ3+E0Xg9+x22ZmFiysenHgmXsoaZUJ
         9vRxCP3Ask+SDpIMf3B4pRdhZ2LwZxb+SxWbnhTSKsXG4FJEgf8frl1Tx3vkN/2oM5k8
         0Cb02Oc9s+oTegzOCWXxzG1VRnnjGbD7N8FbI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=eSZEZ+s5jm/XWtSJuIpYfB8Rxp013Rv0vhhbXCPzESs=;
        b=ViIIblxFAngl2GzNXhSQGUw+wMMMTOlnDxwpna70Bp3uRBNSxf754SCl2eZQjrUDqQ
         kI3CRM8EbekAw8MOGYfm2dAYEmzrzwGU2RaC4Tjv13I1VR9+PtkKRDpIuK/hq7PXZunU
         edxvsLe+pkNZWuXSyB+ROFhnYLXp7/DR4cbW1rDGQXZJI1pDctjgUrxoPt2x/li2nYRZ
         Y3X5a3xaZ1CbEJdScJAZIViU0C0i2juVPikfUgG38ipxd/3wU+ljz8ImQxJcjP06Hh6W
         Nd4Jjw2A4+pjLITMuOM5i7KurfQJR7tTC1GI5ztEE/5ckBwq4w/Fn1+igdGZH2Mr/Yc7
         H3Gg==
X-Gm-Message-State: AOAM532+KGpMZF8w8HqQ1XW5pIqpc7foCGnn+QF5Qt8oQr8iaxvVeQxi
	u8onUkLAUip6X7sXz2iMy/BJ4xqLHTq2xA==
X-Google-Smtp-Source: ABdhPJwcoqxy9CrAQEEtOAA7t51h6Rue4cAntvUt7/T2Eg/tSh+bPS3Cpdc4Y4odnKLhdIRdFWRoGA==
X-Received: by 2002:a05:620a:4548:: with SMTP id u8mr2703639qkp.532.1643897936693;
        Thu, 03 Feb 2022 06:18:56 -0800 (PST)
Received: from meerkat.local (bras-base-mtrlpq5031w-grc-32-216-209-220-127.dsl.bell.ca. [216.209.220.127])
        by smtp.gmail.com with ESMTPSA id g20sm6566071qtk.2.2022.02.03.06.18.56
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 03 Feb 2022 06:18:56 -0800 (PST)
Date: Thu, 3 Feb 2022 09:18:54 -0500
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Harald Hoyer <harald@hoyer.xyz>
Cc: keys@linux.kernel.org
Subject: Re: your mail
Message-ID: <20220203141854.4njybnnzyif2rqhx@meerkat.local>
References: <8bb138a4-061b-ff1e-f702-8492f074cb2d@hoyer.xyz>
Precedence: bulk
X-Mailing-List: keys@linux.kernel.org
List-Id: <keys.linux.kernel.org>
List-Subscribe: <mailto:keys+subscribe@linux.kernel.org>
List-Unsubscribe: <mailto:keys+unsubscribe@linux.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8bb138a4-061b-ff1e-f702-8492f074cb2d@hoyer.xyz>

On Thu, Feb 03, 2022 at 02:41:44PM +0100, Harald Hoyer wrote:

> -----BEGIN PGP PUBLIC KEY BLOCK-----

Updated, thanks.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E7E66FC7
	for <keys@linux.kernel.org>; Wed, 26 Apr 2023 20:54:03 +0000 (UTC)
Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-3ef31b7b868so65706471cf.2
        for <keys@linux.kernel.org>; Wed, 26 Apr 2023 13:54:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linuxfoundation.org; s=google; t=1682542442; x=1685134442;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=ZSOI+YMyj88VQEXie3OkA3BwP4KzWEfkY9f6EFUvVkg=;
        b=Jb3MAKBac24Iy2U88dF+zilU4qN/FgpfyMpiyPrynhYlnKidLyw5renCuibrjzrywg
         O+Oub22gmQEhkY6feEKlD4my29+w304zNXoAtmhbTc8zzUXuQQOZBR+/qiSqpYlNykMq
         sVCQra6YlEx0PidwE8BDKIQkwZkpMjnH+uImI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1682542442; x=1685134442;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZSOI+YMyj88VQEXie3OkA3BwP4KzWEfkY9f6EFUvVkg=;
        b=Ramh/3QzOTHicBvDezzLiv3YMXzSJy7SOSzRrRvsphlLQO47q4v3UC04rwjIarSw5R
         VOqAkyua7LPViRFTdViXIem6MBvmtCNTcaxlV3CjgxKVmYl5dQcjpo9v+o2hSD1YGcNt
         zWY/Wmho+KNn/UgGQS4HloY80rWS9OgzjV1NjW2dH6UwaDn6zsBKIc2ucPHOD+7KKADa
         YfP4tJSu+nXSplGFlQf4z3mfhqOfMHSuMFm7ZL0JjFOkdaI7uGNTEVT/jGUGPK1IGHUB
         vatt21xI2u70OX01iRBCVZAeCECbbU1vgSosUb+AYXnJrhJAOy7g0VwfK7MYhU2TEdmo
         PNSA==
X-Gm-Message-State: AAQBX9cFna3Q4E5G2cRAkKQYCkNrJIA8bvm21l/KjcyOp40Jj0aC0cSQ
	4KA2cvl5CIqywL4aJ4Ncd91O+g==
X-Google-Smtp-Source: AKy350ZoHk0yoYs2D3EixOR/67vRNatb9SfDIFFGCOq4XDbYJU4Fn3Ouk4pcqMV4Gy5fWYXfyF8rtw==
X-Received: by 2002:ac8:7f01:0:b0:3ef:3b5f:9aab with SMTP id f1-20020ac87f01000000b003ef3b5f9aabmr37219171qtk.56.1682542442217;
        Wed, 26 Apr 2023 13:54:02 -0700 (PDT)
Received: from meerkat.local (bras-base-mtrlpq5031w-grc-30-209-226-106-132.dsl.bell.ca. [209.226.106.132])
        by smtp.gmail.com with ESMTPSA id bq24-20020a05622a1c1800b003f018e18c35sm3163304qtb.27.2023.04.26.13.54.01
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 26 Apr 2023 13:54:01 -0700 (PDT)
Date: Wed, 26 Apr 2023 16:54:00 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: keys@linux.kernel.org
Subject: Re: your mail
Message-ID: <20230426-clambake-stoppable-7b0403@meerkat>
References: <ca7c453e-2edb-a27a-43d8-c9111280db26@linaro.org>
Precedence: bulk
X-Mailing-List: keys@linux.kernel.org
List-Id: <keys.linux.kernel.org>
List-Subscribe: <mailto:keys+subscribe@linux.kernel.org>
List-Unsubscribe: <mailto:keys+unsubscribe@linux.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ca7c453e-2edb-a27a-43d8-c9111280db26@linaro.org>

On Wed, Apr 26, 2023 at 03:35:10PM +0100, Bryan O'Donoghue wrote:

> -----BEGIN PGP PUBLIC KEY BLOCK-----

Hello:

There are no signatures on this key that we recognize, so we cannot include it
into the kernel.org keyring. Please get at least 2 signatures from someone who
is already in the keyring (or has a kernel.org account) and resubmit.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8772E54672
	for <keys@linux.kernel.org>; Wed, 14 Feb 2024 14:09:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1707919767; cv=none; b=r0aKaxnBCPtNRlnxEhwBEMo9Ukv7IUYDjruRlZ2XzafIOEPpY90+hlmOwOgHt7SEGMql1hPVm4nT0E6/ZB9YEZ2obOuNJHFT6jDNk/mBvvk5LWX9juetyiURjH5vDMtuCC8+2KQBgpcXRGeMNPsnJ+6FduUixSwgHqXgjBUuVR0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1707919767; c=relaxed/simple;
	bh=lKsM+aOAESDejOLShQ//yI7P4lOVVztkg1funIAOAXg=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Ba3g4GMC+ANe4U2Gy1BMgnaAomli5MYaPRSZ2Q3vwbfveJtc8rd8L2yjyMj+roppFpRpuB7JL2DU6IJAupq4Q1wZD4G5duFNhGymVG1cNTUYWLmL918acjzm6ygvdXm8280FfIqfT4GGEp7MJ+o+XtgQD+JVKQPKy0JSvS0Q2II=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=JH39cCwV; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="JH39cCwV"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4D06C433F1;
	Wed, 14 Feb 2024 14:09:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1707919767;
	bh=lKsM+aOAESDejOLShQ//yI7P4lOVVztkg1funIAOAXg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=JH39cCwVk7BxsSxPvv2p6kE2OFtAa6YRQZimrctFdlCzuDEF4YxoYY5sq68XjEc0H
	 fzWcvYyayzhepWRyfnlVPQinclVBLpF2tFvMbpJ2reKmmNMKEKOEk3Eol0OhUyAn4Z
	 oP8WT/vOIotgsubScWz09j2wyURCjExN/DzgyD6Q=
Date: Wed, 14 Feb 2024 09:09:20 -0500
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: keys@linux.kernel.org
Subject: Re: your mail
Message-ID: <20240214-upbeat-sawfish-of-speed-3ab94e@lemur>
References: <CAPDyKFoP2gVQPJArZJ_DfKXX9a25ASWTyUPQEgvo-74siL=hYg@mail.gmail.com>
Precedence: bulk
X-Mailing-List: keys@linux.kernel.org
List-Id: <keys.linux.kernel.org>
List-Subscribe: <mailto:keys+subscribe@linux.kernel.org>
List-Unsubscribe: <mailto:keys+unsubscribe@linux.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAPDyKFoP2gVQPJArZJ_DfKXX9a25ASWTyUPQEgvo-74siL=hYg@mail.gmail.com>

On Fri, Feb 09, 2024 at 01:30:34PM +0100, Ulf Hansson wrote:
> -----BEGIN PGP PUBLIC KEY BLOCK-----

Updated, thanks.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: your mail
Date: Thu, 24 Jan 2013 15:12:40 -0800
Message-ID: <20130124231240.GN26407@google.com>
References: <C4B5704C6FEB5244B2A1BCC8CF83B86B0A6257C7D0@MYMBX.MY.STEC-INC.AD>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-bcache-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <C4B5704C6FEB5244B2A1BCC8CF83B86B0A6257C7D0-AQg6BlXVjylhNUoibfp7lHKnxlUjViKd@public.gmane.org>
Sender: linux-bcache-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Nitin Kshirsagar <nshirsagar-FZ1t8LVTR2ZWk0Htik3J/w@public.gmane.org>
Cc: "linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Amit Kale <akale-FZ1t8LVTR2ZWk0Htik3J/w@public.gmane.org>, Sanoj Unnikrishnan <sunnikrishnan-FZ1t8LVTR2ZWk0Htik3J/w@public.gmane.org>
List-Id: linux-bcache@vger.kernel.org

On Wed, Jan 23, 2013 at 08:37:10PM +0800, Nitin Kshirsagar wrote:
> Hello Kent,
> 
> I have setup bcache and run fio data verification test on write back and write through caches.
> The fio tests are passed, however I have found following issues while using bcache.
> 
> Issue1: Cache is not created as per user specified options  
> --------------------------------------------------------------------------------------------------------
> Steps:
> 1.Create cache by specifying mode writeback and cache replacement policy as fifo
> [root@annu bcache]# make-bcache --cache  /dev/sdc --bdev /dev/sdd  --writeback --cache_replacement_policy=fifo 
> UUID:                   e25f2840-f02b-46af-81e7-28948b2737cc
> Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
> nbuckets:               2048
> block_size:             1
> bucket_size:            1024
> nr_in_set:              1
> nr_this_dev:            0
> first_bucket:           1
> UUID:                   a3ce52e6-631b-4c74-afa2-9f8b0088c7f4
> Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
> nbuckets:               20480
> block_size:             1
> bucket_size:            1024
> nr_in_set:              1
> nr_this_dev:            0
> first_bucket:           1
> 
> [root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
> [root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
> 
> 
> 2. Cache mode should  be "writeback" instead of "writethrough"
> [root@annu bcache]# cat /sys/block/bcache2/bcache/cache_mode
> [writethrough] writeback writearound none
> [root@annu bcache]# cat /sys/block/bcache2/bcache/writeback_running
> 1
> 
> 3. Cache policy should be "fifo" instead of "lru" 
> [root@annu ~]# cat /sys/block/bcache2/bcache/cache/cache0/cache_replacement_policy
> [lru] fifo random

These two are... oddities/documentation bugs with make-bcache. Options
apply to devices you specify _after_ the option, not before - it was
implemented this way so you could format cache devices and backing
devices at the same time - and really, the other options should be
parsed differently but I haven't spent much time on make-bcache.

Patches welcome :)

> Issue2: Cache dirty data value should not be negative.
> -------------------------------------------------------------------------------------------------------
> Steps:
> 
> 1.Create cache by specifying mode writeback and cache replacement policy as fifo
> 2.To make bcache devices known to the kernel
>     [root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
>     [root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
> 3.Create FS on cache  /dev/bcacheN and mount in directory
> 4.Create Data set by using fio or dd on mount point.
> 5. Change cache node from "writethrough" to "writeback"    
>     [root@annu ~]# echo writeback >  /sys/block/bcache2/bcache/cache_mode
>     [root@annu ~]# cat /sys/block/bcache2/bcache/cache_mode
>     writethrough [writeback] writearound none
> 6.Check cache dirty data should not be negative value 
>    [root@annu ~]# cat /sys/block/bcache2/bcache/dirty_data
>    -9.4M

Known bug, but fairly harmless one. That value is only used for the pd
controller that adjusts the background writeback rate - and in practice
when there's dirty data in the cache it shouldn't be _too_ far off.

It's on the todo list, but it'll be a bit before I get to it.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arch-owner@vger.kernel.org>
Received: from rhun.apana.org.au ([64.62.148.172]:1435 "EHLO
	arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
	with ESMTP id S1752840AbXHPAcz (ORCPT
	<rfc822;linux-arch@vger.kernel.org>); Wed, 15 Aug 2007 20:32:55 -0400
Date: Thu, 16 Aug 2007 08:32:26 +0800
From: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: your mail
Message-ID: <20070816003226.GA29491@gondor.apana.org.au>
References: <46C30540.2070603@s5r6.in-berlin.de> <alpine.LFD.0.999.0708151941150.16414@enigma.security.iitk.ac.in> <20070815145207.GA23106@gondor.apana.org.au> <46C3253F.5090707@s5r6.in-berlin.de> <20070815162722.GD9645@linux.vnet.ibm.com> <d4406222873856f472b9173a14a19aa2@kernel.crashing.org> <20070815185724.GH9645@linux.vnet.ibm.com> <alpine.LFD.0.999.0708160118330.16414@enigma.security.iitk.ac.in> <2d2eeab6276cab2e6cc5830d36a43b98@kernel.crashing.org> <alpine.LFD.0.999.0708160338520.22701@enigma.security.iitk.ac.in>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.0.999.0708160338520.22701@enigma.security.iitk.ac.in>
Sender: linux-arch-owner@vger.kernel.org
To: Satyam Sharma <satyam@infradead.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>, horms@verge.net.au, Stefan Richter <stefanr@s5r6.in-berlin.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, ak@suse.de, netdev@vger.kernel.org, cfriesen@nortel.com, Heiko Carstens <heiko.carstens@de.ibm.com>, rpjday@mindspring.com, jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, zlynx@acm.org, clameter@sgi.com, schwidefsky@de.ibm.com, Chris Snook <csnook@redhat.com>, davem@davemloft.net, Linus Torvalds <torvalds@linux-foundation.org>, wensong@linux-vs.org, wjiang@resilience.com
List-ID: <linux-arch.vger.kernel.org>

On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wrote:
> 
> that are:
> 
> 	while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
> 		mdelay(1);
> 		msecs--;
> 	}
> 
> where mdelay() becomes __const_udelay() which happens to be in another
> translation unit (arch/i386/lib/delay.c) and hence saves this callsite
> from being a bug :-)

The udelay itself certainly should have some form of cpu_relax in it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arch-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id C0156C71155
	for <linux-arch@archiver.kernel.org>; Wed,  2 Dec 2020 18:52:44 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 606C221741
	for <linux-arch@archiver.kernel.org>; Wed,  2 Dec 2020 18:52:44 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2387819AbgLBSwL (ORCPT <rfc822;linux-arch@archiver.kernel.org>);
        Wed, 2 Dec 2020 13:52:11 -0500
Received: from mga04.intel.com ([192.55.52.120]:56541 "EHLO mga04.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1729000AbgLBSwK (ORCPT <rfc822;linux-arch@vger.kernel.org>);
        Wed, 2 Dec 2020 13:52:10 -0500
IronPort-SDR: aiHqgaIgp9BtKoyXKlFVwYb0v5HRmAslhcvHXqkC/XVy+Y8LwR1HL+IAMMktBZCu6by/t9qWKo
 L6Dq5BF6zUUg==
X-IronPort-AV: E=McAfee;i="6000,8403,9823"; a="170502004"
X-IronPort-AV: E=Sophos;i="5.78,387,1599548400"; 
   d="scan'208";a="170502004"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
  by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 10:50:30 -0800
IronPort-SDR: f5ZeDIycbNzT7S5s+5pjjkfqOQELvXr/smb2b9H4sD2vZZ15lwZmwASAPT9mTVVJTVePb59Oli
 uoHsXSrAdc5Q==
X-IronPort-AV: E=Sophos;i="5.78,387,1599548400"; 
   d="scan'208";a="335664784"
Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40])
  by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 10:50:26 -0800
Received: from andy by smile with local (Exim 4.94)
        (envelope-from <andriy.shevchenko@linux.intel.com>)
        id 1kkXDr-00Ba4b-LT; Wed, 02 Dec 2020 20:51:27 +0200
Date:   Wed, 2 Dec 2020 20:51:27 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Yun Levi <ppbuk5246@gmail.com>
Cc:     Yury Norov <yury.norov@gmail.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>, dushistov@mail.ru,
        Arnd Bergmann <arnd@arndb.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        William Breathitt Gray <vilhelm.gray@gmail.com>,
        richard.weiyang@linux.alibaba.com, joseph.qi@linux.alibaba.com,
        skalluru@marvell.com, Josh Poimboeuf <jpoimboe@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arch@vger.kernel.org
Subject: Re: your mail
Message-ID: <20201202185127.GO4077@smile.fi.intel.com>
References: <CAM7-yPQcmU3MM66oAHQ6kcEukPFgj074_h-S-S+O53Lrx2yeBg@mail.gmail.com>
 <20201202094717.GX4077@smile.fi.intel.com>
 <c79b08e9-d36a-849e-d023-6fa155043aa9@rasmusvillemoes.dk>
 <CAM7-yPTsy+wJO8oQ7srjiXk+VjFFSUdJfdnVx9Ma_H8jJJnZKA@mail.gmail.com>
 <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
 <20201202173701.GM4077@smile.fi.intel.com>
 <CAM7-yPSWvsySweXSmbvW2hucce8T7BOSkz-eF5t7PJE6zv5tjg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAM7-yPSWvsySweXSmbvW2hucce8T7BOSkz-eF5t7PJE6zv5tjg@mail.gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk
List-ID: <linux-arch.vger.kernel.org>
X-Mailing-List: linux-arch@vger.kernel.org

On Thu, Dec 03, 2020 at 03:27:33AM +0900, Yun Levi wrote:
> On Thu, Dec 3, 2020 at 2:36 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Dec 02, 2020 at 09:26:05AM -0800, Yury Norov wrote:

...

> > Side note: speaking of performance, any plans to fix for_each_*_bit*() for
> > cases when the nbits is known to be <= BITS_PER_LONG?
> >
> > Now it makes an awful code generation (something like few hundred bytes of
> > code).

> Frankly Speaking, I don't have an idea in now.....
> Could you share your idea or wisdom?

Something like (I may be mistaken by names, etc, I'm not a compiler expert,
and this is in pseudo language, I don't remember all API names by hart,
just to express the idea) as a rough first step

__builtin_constant(nbits, find_next_set_bit_long, find_next_set_bit)

find_next_set_bit_long()
{
	unsigned long v = BIT_LAST_WORD(i);
	return ffs_long(v);
}

Same for find_first_set_bit() -> map it to ffs_long().

And I believe it can be optimized more.

-- 
With Best Regards,
Andy Shevchenko



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arch-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 451D3C71156
	for <linux-arch@archiver.kernel.org>; Wed,  2 Dec 2020 18:57:33 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id D29242224F
	for <linux-arch@archiver.kernel.org>; Wed,  2 Dec 2020 18:57:32 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2388005AbgLBS5c (ORCPT <rfc822;linux-arch@archiver.kernel.org>);
        Wed, 2 Dec 2020 13:57:32 -0500
Received: from mga18.intel.com ([134.134.136.126]:41673 "EHLO mga18.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2387784AbgLBS5c (ORCPT <rfc822;linux-arch@vger.kernel.org>);
        Wed, 2 Dec 2020 13:57:32 -0500
IronPort-SDR: VgJFp9Z0cGFMgr3cYOymhhPSp1gVz2C9mODCwDvT91XJvJ22RpUP6lGVab/5NpIk85qeoY7GOM
 G2T0iSwYaaxg==
X-IronPort-AV: E=McAfee;i="6000,8403,9823"; a="160838543"
X-IronPort-AV: E=Sophos;i="5.78,387,1599548400"; 
   d="scan'208";a="160838543"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga003.jf.intel.com ([10.7.209.27])
  by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 10:55:33 -0800
IronPort-SDR: 9pF10d0HmH3irEVZYigo5mCPyQXJtKfIC8I0GY0wWLkdTy7Qr+1ynmH+qfBtC9yiXwiEEUJq+3
 T1kdNiddENHw==
X-IronPort-AV: E=Sophos;i="5.78,387,1599548400"; 
   d="scan'208";a="330562629"
Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40])
  by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 10:55:30 -0800
Received: from andy by smile with local (Exim 4.94)
        (envelope-from <andriy.shevchenko@linux.intel.com>)
        id 1kkXIl-00Ba88-PW; Wed, 02 Dec 2020 20:56:31 +0200
Date:   Wed, 2 Dec 2020 20:56:31 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Yun Levi <ppbuk5246@gmail.com>
Cc:     Yury Norov <yury.norov@gmail.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>, dushistov@mail.ru,
        Arnd Bergmann <arnd@arndb.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        William Breathitt Gray <vilhelm.gray@gmail.com>,
        richard.weiyang@linux.alibaba.com, joseph.qi@linux.alibaba.com,
        skalluru@marvell.com, Josh Poimboeuf <jpoimboe@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arch@vger.kernel.org
Subject: Re: your mail
Message-ID: <20201202185631.GQ4077@smile.fi.intel.com>
References: <CAM7-yPQcmU3MM66oAHQ6kcEukPFgj074_h-S-S+O53Lrx2yeBg@mail.gmail.com>
 <20201202094717.GX4077@smile.fi.intel.com>
 <c79b08e9-d36a-849e-d023-6fa155043aa9@rasmusvillemoes.dk>
 <CAM7-yPTsy+wJO8oQ7srjiXk+VjFFSUdJfdnVx9Ma_H8jJJnZKA@mail.gmail.com>
 <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
 <20201202173701.GM4077@smile.fi.intel.com>
 <CAM7-yPSWvsySweXSmbvW2hucce8T7BOSkz-eF5t7PJE6zv5tjg@mail.gmail.com>
 <20201202185127.GO4077@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201202185127.GO4077@smile.fi.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk
List-ID: <linux-arch.vger.kernel.org>
X-Mailing-List: linux-arch@vger.kernel.org

On Wed, Dec 02, 2020 at 08:51:27PM +0200, Andy Shevchenko wrote:
> On Thu, Dec 03, 2020 at 03:27:33AM +0900, Yun Levi wrote:
> > On Thu, Dec 3, 2020 at 2:36 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Dec 02, 2020 at 09:26:05AM -0800, Yury Norov wrote:

...

> > > Side note: speaking of performance, any plans to fix for_each_*_bit*() for
> > > cases when the nbits is known to be <= BITS_PER_LONG?
> > >
> > > Now it makes an awful code generation (something like few hundred bytes of
> > > code).
> 
> > Frankly Speaking, I don't have an idea in now.....
> > Could you share your idea or wisdom?
> 
> Something like (I may be mistaken by names, etc, I'm not a compiler expert,
> and this is in pseudo language, I don't remember all API names by hart,
> just to express the idea) as a rough first step
> 
> __builtin_constant(nbits, find_next_set_bit_long, find_next_set_bit)
> 
> find_next_set_bit_long()
> {
> 	unsigned long v = BIT_LAST_WORD(i);
> 	return ffs_long(v);
> }
> 
> Same for find_first_set_bit() -> map it to ffs_long().
> 
> And I believe it can be optimized more.

Btw it will also require to reconsider test cases where such constant small
nbits values are passed (forcing compiler to avoid optimization somehow, one
way is to try random nbits for some test cases).

-- 
With Best Regards,
Andy Shevchenko



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=N6CR=BX=vger.kernel.org=linux-arm-msm-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 2697FC433E1
	for <linux-arm-msm@archiver.kernel.org>; Thu, 13 Aug 2020 07:08:19 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 00A2E20866
	for <linux-arm-msm@archiver.kernel.org>; Thu, 13 Aug 2020 07:08:18 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Fklxr+GN"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726604AbgHMHIS (ORCPT
        <rfc822;linux-arm-msm@archiver.kernel.org>);
        Thu, 13 Aug 2020 03:08:18 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59108 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726529AbgHMHIR (ORCPT
        <rfc822;linux-arm-msm@vger.kernel.org>);
        Thu, 13 Aug 2020 03:08:17 -0400
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CE8FC061757
        for <linux-arm-msm@vger.kernel.org>; Thu, 13 Aug 2020 00:08:17 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id m71so2355348pfd.1
        for <linux-arm-msm@vger.kernel.org>; Thu, 13 Aug 2020 00:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=oXHNkcnjdKbtST/Cm72EMU54y/enkmsrbD67DAs+07Q=;
        b=Fklxr+GNMBRv9AdOmZve+uLJ4LVS10Wd3Efz0ihbZTLMTOPOgReJJykQoZcjwpyjjS
         d4rRk8uWKwlA8L0irHe9fQ+OspRENYO6F/zcD9N/Mlxe4qKRj4EGAhNVUA8nl1b9969x
         tjZWGCjF6mJmHcYf5Y5y3Jb2zwct9S+zg1BSwNwGmOjkHim50IkRMlgAhdmJqNqCjlqO
         VME/tlWH6CN8XMVXFHBLEBlJGUVmRPf5nIVitK+qSrEW+YLa2AdGrWldO53L2xn6d3a6
         hx9/RDRBygqotoV08G4c9S8WQs00HkQy9YbiChcAzlnvXkACAF33vSzFNnJCojz62lJU
         ZqyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=oXHNkcnjdKbtST/Cm72EMU54y/enkmsrbD67DAs+07Q=;
        b=B/c7z5dPa7jWtTZOg1YkbplJlz0iQT3D7q1g86YpZLberABX4J+7foHHNNLBrBjl1w
         tsrWUJuMe+ED5vzzHCs+zkc8BUyk0Ch4gQCdQbi8apI5O9z34vEcauLRx2QU0uA1Jfhj
         xsLlFuDLTgHpU5stnzzV+K2nDelK+C9v0ST67ccmeaUFKReFp9oqniaWz6SCyvjNAy41
         h6dybCe8AFtF9ICOR0XHmcAtzgrmAdQbX3YSuNBSqlTd6V4P37ykiMVhvxVRouq1f3XK
         bTYG5l9BhsG4iV+HW2OG7PEugihxJrV9UfxvRuHdc2slSr5OsA6yi6gFwlEx3VOltQZF
         +u1A==
X-Gm-Message-State: AOAM5329L8jJ5Y+u6ZBgNyvQ3R+WNZz37hLSqrXxSCncG+MFet7Snme2
        nt8xYLpt4A6GCjqQq/K4V0UU+w==
X-Google-Smtp-Source: ABdhPJy5mTa6bjpMvZNEqyus64np+Q1hqEXWGxyB6FdFHAaKwxpJXm138hVyyVcESnvJqC/jue2U6g==
X-Received: by 2002:a62:2e45:: with SMTP id u66mr3107106pfu.121.1597302496590;
        Thu, 13 Aug 2020 00:08:16 -0700 (PDT)
Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28])
        by smtp.gmail.com with ESMTPSA id t10sm4260202pgp.15.2020.08.13.00.08.15
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 13 Aug 2020 00:08:15 -0700 (PDT)
Date:   Thu, 13 Aug 2020 00:04:48 -0700
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Konrad Dybcio <konradybcio@gmail.com>
Cc:     amit.pundir@linaro.org, agross@kernel.org,
        devicetree@vger.kernel.org, john.stultz@linaro.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        robh+dt@kernel.org, sumit.semwal@linaro.org
Subject: Re: your mail
Message-ID: <20200813070448.GA499758@builder.lan>
References: <CAMi1Hd3Dv_T7kgThLTk2QLtfS7LBvhJ5R=6C3seUYK0GvNV6eA@mail.gmail.com>
 <20200806223134.42748-1-konradybcio@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200806223134.42748-1-konradybcio@gmail.com>
Sender: linux-arm-msm-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-arm-msm.vger.kernel.org>
X-Mailing-List: linux-arm-msm@vger.kernel.org

On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:

> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> 
> >// This removed_region is needed to boot the device
> >               // TODO: Find out the user of this reserved memory
> >               removed_region: memory@88f00000 {
> 
> This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> 

This is in line with what the documentation indicates and then it would
be better to just bump &tz_mem to a size of 0x4900000.

Regards,
Bjorn

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=BLIn=B3=vger.kernel.org=linux-arm-msm-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 4069BC433E1
	for <linux-arm-msm@archiver.kernel.org>; Mon, 17 Aug 2020 17:13:23 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 1B1362067C
	for <linux-arm-msm@archiver.kernel.org>; Mon, 17 Aug 2020 17:13:23 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Gpu1742R"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2389475AbgHQRNJ (ORCPT
        <rfc822;linux-arm-msm@archiver.kernel.org>);
        Mon, 17 Aug 2020 13:13:09 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49794 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2388645AbgHQRMl (ORCPT
        <rfc822;linux-arm-msm@vger.kernel.org>);
        Mon, 17 Aug 2020 13:12:41 -0400
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B364CC061343
        for <linux-arm-msm@vger.kernel.org>; Mon, 17 Aug 2020 10:12:40 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id f7so15744504wrw.1
        for <linux-arm-msm@vger.kernel.org>; Mon, 17 Aug 2020 10:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=AueLUpVNwOplEaRIeklXnlMpQk/hv9PNTq+/4iLo0R0=;
        b=Gpu1742R6bQKiE7BaePK5diMLvF+iZfSSkZ0BOARPwt42lhi8nz00uW6K89/MGg4zm
         hZXZDUrk/4N+XUcR0wbbQo713rcnKWaOX9p4s60ZhAx89+KzEZhhA4saULYqOxNRGYdx
         hUyQy65h8Dy4+B9yFynN1Kh1R/12oHa6Gs3j4u3Q4o3r9uQOP6RgH+35nG01K9CZdK68
         rzoGzIXjOR9WHXTKTHVQO9vD4+jdCw3iMYQLPoCTJcpW+4tvowsYeLvIo21HjWRa2vmV
         04Cx09aiVDy2hFLu9lZ+jRZdQNHnPp6FILixg0q9oSK7M9y8md8BFE7vFrK7eGa8X8yl
         WMrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=AueLUpVNwOplEaRIeklXnlMpQk/hv9PNTq+/4iLo0R0=;
        b=tb4ow4/xXuq0zQv0wdQ9BUGDOjE5R+UMisc25TN24gj5KZi/kwCyKvyAwfg5SC8cL3
         GgjKdnJvFVo9coe4U9u3whlxJHlAvmpH1N7LIR1mGESn1Ig3oin54EYhQWudncYYeg28
         1tyxZEv4oRyzAW1ve/xYqg/A+VZeNyS82hieGARXTt36cdCvIrtNzutrzvAvEDS3b0nh
         I7nManNKYaozTh+HvybV7H5jDgU6bpfTRRRc17ZNcke8X1I6JROtFuTHXtsvBb2TvwuD
         4h2zphGIIOaeQZrrXSXkTqb24eWLHOscO49hI/LmwoIu557IiIy2WZX2Biw7g7pmCQ4q
         kNlA==
X-Gm-Message-State: AOAM531R9PtkA/6729QGB5fqIQ1T55p6LAQfowYLo+oJlzSFfsIRgNr+
        QK6P5MjF183utnFo/elkMud2+NZ36l0gYr7FhVFSOA==
X-Google-Smtp-Source: ABdhPJwzzJqqKP8Dz57WEH4mjrx29gWDTGQSyhqQk/3EQMn3h+P+wfHkvWUG7jnjma/rWD/FdEgspqJzfrhXMf85F+M=
X-Received: by 2002:adf:fc06:: with SMTP id i6mr16257949wrr.79.1597684357045;
 Mon, 17 Aug 2020 10:12:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAMi1Hd3Dv_T7kgThLTk2QLtfS7LBvhJ5R=6C3seUYK0GvNV6eA@mail.gmail.com>
 <20200806223134.42748-1-konradybcio@gmail.com> <20200813070448.GA499758@builder.lan>
In-Reply-To: <20200813070448.GA499758@builder.lan>
From:   Amit Pundir <amit.pundir@linaro.org>
Date:   Mon, 17 Aug 2020 22:42:00 +0530
Message-ID: <CAMi1Hd3j-A1Se9swD0TQ9YzTBGicPDc1nFZbf4uisVk5A+u1GQ@mail.gmail.com>
Subject: Re: your mail
To:     Bjorn Andersson <bjorn.andersson@linaro.org>
Cc:     Konrad Dybcio <konradybcio@gmail.com>,
        Andy Gross <agross@kernel.org>,
        dt <devicetree@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Sumit Semwal <sumit.semwal@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-arm-msm-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-arm-msm.vger.kernel.org>
X-Mailing-List: linux-arm-msm@vger.kernel.org

On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
>
> > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> >
> > >// This removed_region is needed to boot the device
> > >               // TODO: Find out the user of this reserved memory
> > >               removed_region: memory@88f00000 {
> >
> > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> >
>
> This is in line with what the documentation indicates and then it would
> be better to just bump &tz_mem to a size of 0x4900000.

Hi, so just to be sure that I got this right, you want me to extend
&tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
including this downstream &removed_region (of size 0x1A00000) +
previously unreserved downstream memory region (of size 0x200000), to
align with the starting address of &qseecom_mem?

I just gave this &tz_mem change a spin and I do not see any obvious
regression in my limited smoke testing (Boots AOSP to UI with
v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.

Regards,
Amit Pundir

>
> Regards,
> Bjorn

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=dmXq=CI=vger.kernel.org=linux-arm-msm-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 6DF26C433E6
	for <linux-arm-msm@archiver.kernel.org>; Sun, 30 Aug 2020 18:59:06 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 4105C208CA
	for <linux-arm-msm@archiver.kernel.org>; Sun, 30 Aug 2020 18:59:06 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="WvWUDcgu"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726326AbgH3S7F (ORCPT
        <rfc822;linux-arm-msm@archiver.kernel.org>);
        Sun, 30 Aug 2020 14:59:05 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33892 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726178AbgH3S7C (ORCPT
        <rfc822;linux-arm-msm@vger.kernel.org>);
        Sun, 30 Aug 2020 14:59:02 -0400
Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BC3CC061573
        for <linux-arm-msm@vger.kernel.org>; Sun, 30 Aug 2020 11:59:01 -0700 (PDT)
Received: by mail-qv1-xf41.google.com with SMTP id m14so411743qvt.1
        for <linux-arm-msm@vger.kernel.org>; Sun, 30 Aug 2020 11:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=lUMKQLlBSJCarKsSu0GjI45SsOuLiQU3I20h0koncyY=;
        b=WvWUDcguQ3mKtncotDNXG+mBPq9NyvJv9t7WpxvwJ96ZIj6fnKG2qm6ZK8LIqVQAr+
         kYOvS0hYk8MXGbZucOJqZJKKUDQ6tj/dr5bGEaYICOO2pIbEj9Rm5xWZDJOBIS6RlOL7
         ngPuGNcAIgjrI7fWarHAncCoHq21UoDkbGfwkeQ9O6gc0SAv5oHS6N8k8kvbP7yFqKUr
         yTDkP9ELUKo9roSiT+rEP+wYlDVeVLGGSd9gE1OjCWchS1e4YlTAaiGzYqfw5lcLFFVo
         jVPIQko0qxMHSHXZeeGRkU+iV3Czu8PZydpLfptDKlw/UldaEFGp7A8VxDJV8vjirIe3
         xgrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=lUMKQLlBSJCarKsSu0GjI45SsOuLiQU3I20h0koncyY=;
        b=bAcmYWpsjnVzQEl9PgF19oJnm8QoNU5lpuaJJ0VzDdyo+7Yoc51DdPwtDZ9Qm9Qnbo
         ePOUjA98ks8TvAZNhkFwf5SD5abrhbUkxc6aQIoEgG9creKThBtA6yF4iX18ODvaFpjS
         egjvj94hzS99U4/z1n7tCT4yFgTcpnw6ptyCAXMibtp2zjOXFHx82bspOHapcBBq7fnp
         gSHF5hiGTv0PfJCcAna6iagdi3z/2Gb7Ef/w6nus/oNsh70F77aUszQOjwr2QVl+BUnc
         qwT69gql8hWZWuQVMkgbqZIMs3dpfu+qnhG221NStr8B2MO2zjeU3WgS4g1sfn7Q0ys3
         qLBA==
X-Gm-Message-State: AOAM5336AxPDdJUwRu5Ey50h7mkJ2tLxina7pgPYXgKugGLqE1gdrQc2
        5d7SG4ckisZqhbOWMeyOnJdYkA==
X-Google-Smtp-Source: ABdhPJzVuLSEAXfc5i2H+uVW+pqJ7JPE9Po3NtUqrMnVy/uGx1VZFC8jdwxXC/5i+jNQ+IcThz62+A==
X-Received: by 2002:a0c:fdc4:: with SMTP id g4mr3795975qvs.30.1598813940154;
        Sun, 30 Aug 2020 11:59:00 -0700 (PDT)
Received: from uller (ec2-34-197-84-77.compute-1.amazonaws.com. [34.197.84.77])
        by smtp.gmail.com with ESMTPSA id c9sm265256qkg.46.2020.08.30.11.58.59
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 30 Aug 2020 11:58:59 -0700 (PDT)
Date:   Sun, 30 Aug 2020 18:58:57 +0000
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Amit Pundir <amit.pundir@linaro.org>
Cc:     Konrad Dybcio <konradybcio@gmail.com>,
        Andy Gross <agross@kernel.org>,
        dt <devicetree@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: your mail
Message-ID: <20200830185857.GD1947@uller>
References: <CAMi1Hd3Dv_T7kgThLTk2QLtfS7LBvhJ5R=6C3seUYK0GvNV6eA@mail.gmail.com>
 <20200806223134.42748-1-konradybcio@gmail.com>
 <20200813070448.GA499758@builder.lan>
 <CAMi1Hd3j-A1Se9swD0TQ9YzTBGicPDc1nFZbf4uisVk5A+u1GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMi1Hd3j-A1Se9swD0TQ9YzTBGicPDc1nFZbf4uisVk5A+u1GQ@mail.gmail.com>
Sender: linux-arm-msm-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-arm-msm.vger.kernel.org>
X-Mailing-List: linux-arm-msm@vger.kernel.org

On Mon 17 Aug 17:12 UTC 2020, Amit Pundir wrote:

> On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> >
> > > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> > >
> > > >// This removed_region is needed to boot the device
> > > >               // TODO: Find out the user of this reserved memory
> > > >               removed_region: memory@88f00000 {
> > >
> > > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> > >
> >
> > This is in line with what the documentation indicates and then it would
> > be better to just bump &tz_mem to a size of 0x4900000.
> 
> Hi, so just to be sure that I got this right, you want me to extend
> &tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
> including this downstream &removed_region (of size 0x1A00000) +
> previously unreserved downstream memory region (of size 0x200000), to
> align with the starting address of &qseecom_mem?
> 

Yes

Regards,
Bjorn

> I just gave this &tz_mem change a spin and I do not see any obvious
> regression in my limited smoke testing (Boots AOSP to UI with
> v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
> 
> Regards,
> Amit Pundir
> 
> >
> > Regards,
> > Bjorn

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arm-msm-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham
	autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 75DD5C433B4
	for <linux-arm-msm@archiver.kernel.org>; Wed,  7 Apr 2021 06:56:47 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 27AD5610C8
	for <linux-arm-msm@archiver.kernel.org>; Wed,  7 Apr 2021 06:56:47 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1345855AbhDGG4z (ORCPT
        <rfc822;linux-arm-msm@archiver.kernel.org>);
        Wed, 7 Apr 2021 02:56:55 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60804 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S242439AbhDGG4y (ORCPT
        <rfc822;linux-arm-msm@vger.kernel.org>);
        Wed, 7 Apr 2021 02:56:54 -0400
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A041C06174A
        for <linux-arm-msm@vger.kernel.org>; Tue,  6 Apr 2021 23:56:44 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id l76so12285640pga.6
        for <linux-arm-msm@vger.kernel.org>; Tue, 06 Apr 2021 23:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to:user-agent;
        bh=qlzTZxMrHlq9IaqoYKOJhu98bRmyXXyoDWHeXFeO+Y4=;
        b=S7iJhWrBVnhGLodRiVAEYpbEsjKXcw36YgsCvXSjljjp6i6wKWJ9cYhc2vpHOm9yFT
         SVcL3hqCEe14me2bFzG7Zei5iXci3bSEhBKMZ9pdEXeQADcsQzYuyCXILXut1qSEsWOs
         Do71CGaJO3dntbwkxCovcRu5yK6r0e1BiFdmrWFRLpObGfsDWaPM0Kp+8wz5O8JZYRIR
         ryRR9gEZ19ZYRP2I0fkJ+SNsNi9gGdSi0P9QbL6GIVGt2CGse0f4+CzXVPlb9fJaEiub
         5pMy9O4jfSwlC2gkZHiVS0/i8B9X4qRpvGfRa3cUI/hndGF83/mgAqaUPoq3U91XR9z6
         KMGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to:user-agent;
        bh=qlzTZxMrHlq9IaqoYKOJhu98bRmyXXyoDWHeXFeO+Y4=;
        b=dZBJCtdTAbIVtHiqFNcYGwJ0VpNFemoVaEWSlafJ08+VnFdje0cc95alSTRSpBOA22
         3OtZ+5ZFb4KKkRcyo2h/G5fKtlxmlHI5wdjluuSdz+bQZMlabvriS3QzioINjqQAx9Ez
         yhfuG7xAGhqVfDZ9MFsFGfat+p02r9hpBlO+yKEkUIo/EQ1Y6uGKRB3nCYZnHRrsMx0Z
         05kxNUvzEIUd3XhhdnlOOr8bVTdKUfWs5xufslwrvjWDJo/c1pBsJuf+o8lQnIb+zALB
         PokpVl1L1ubSkN0hEQVyCngV0jpNwmdBrxYBEAJAXSmSduYEN8MiglpSBo4L+5iu6wvl
         bqIQ==
X-Gm-Message-State: AOAM530OyN3aGhZ3Ik9AFl0Q6yN/2Md8WA6bBKSbrjP56KR7373w74YV
        5lo/nwkYVTRcEPoG7s4vbR28
X-Google-Smtp-Source: ABdhPJxfVatsZMv7+MAExdQodk/gPS37IrjWs/+GZhw62k+votfbyNuu4FQhziXufV+UJfaUVxB/Mg==
X-Received: by 2002:a63:48c:: with SMTP id 134mr1937231pge.347.1617778603893;
        Tue, 06 Apr 2021 23:56:43 -0700 (PDT)
Received: from work ([103.77.37.180])
        by smtp.gmail.com with ESMTPSA id p5sm4315078pfg.85.2021.04.06.23.56.41
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Tue, 06 Apr 2021 23:56:43 -0700 (PDT)
Date:   Wed, 7 Apr 2021 12:26:39 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To:     Bhaumik Bhatt <bbhatt@codeaurora.org>
Cc:     linux-arm-msm@vger.kernel.org, hemantk@codeaurora.org,
        jhugo@codeaurora.org, linux-kernel@vger.kernel.org,
        carl.yin@quectel.com, naveen.kumar@quectel.com,
        loic.poulain@linaro.org
Subject: Re: your mail
Message-ID: <20210407065639.GM8675@work>
References: <1617311778-1254-1-git-send-email-bbhatt@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1617311778-1254-1-git-send-email-bbhatt@codeaurora.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk
List-ID: <linux-arm-msm.vger.kernel.org>
X-Mailing-List: linux-arm-msm@vger.kernel.org

On Thu, Apr 01, 2021 at 02:16:09PM -0700, Bhaumik Bhatt wrote:
> Subject: [PATCH v8 0/9] Updates to MHI channel handling
> 

Subject is present in the body ;)

> MHI specification shows a state machine with support for STOP channel command
> and the validity of certain state transitions. MHI host currently does not
> provide any mechanism to stop a channel and restart it without resetting it.
> There are also times when the device moves on to a different execution
> environment while client drivers on the host are unaware of it and still
> attempt to reset the channels facing unnecessary timeouts.
> 
> This series addresses the above areas to provide support for stopping an MHI
> channel, resuming it back, improved documentation and improving upon channel
> state machine handling in general.
> 
> This set of patches was tested on arm64 and x86_64 architecture.
> 

Series applied to mhi-next!

Thanks,
Mani

> v8:
> -Split the state machine improvements patch to three patches as per review
> 
> v7:
> -Tested on x86_64 architecture
> -Drop the patch "Do not clear channel context more than once" as issue is fixed
> differently using "bus: mhi: core: Fix double dma free()"
> -Update the commit text to better reflect changes on state machine improvements
> 
> v6:
> -Dropped the patch which introduced start/stop transfer APIs for lack of users
> -Updated error handling and debug prints on channel handling improvements patch
> -Improved commit text to better explain certain patches based on review comments
> -Removed references to new APIs from the documentation improvement patch
> 
> v5:
> -Added reviewed-by tags from Hemant I missed earlier
> -Added patch to prevent kernel warnings on clearing channel context twice
> 
> v4:
> -Updated commit text/descriptions and addressed checkpatch checks
> -Added context validity check before starting/stopping channels from new API
> -Added patch to clear channel context configuration after reset/unprepare
> 
> v3:
> -Updated documentation for channel transfer APIs to highlight differences
> -Create separate patch for "allowing channel to be disabled from stopped state"
> 
> v2:
> -Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
> -Added improved documentation to avoid confusion with the new APIs
> -Removed the __ prefix from mhi_unprepare_channel() API for consistency.
> 
> Bhaumik Bhatt (9):
>   bus: mhi: core: Allow sending the STOP channel command
>   bus: mhi: core: Clear context for stopped channels from remove()
>   bus: mhi: core: Improvements to the channel handling state machine
>   bus: mhi: core: Update debug messages to use client device
>   bus: mhi: core: Hold device wake for channel update commands
>   bus: mhi: core: Clear configuration from channel context during reset
>   bus: mhi: core: Check channel execution environment before issuing
>     reset
>   bus: mhi: core: Remove __ prefix for MHI channel unprepare function
>   bus: mhi: Improve documentation on channel transfer setup APIs
> 
>  drivers/bus/mhi/core/init.c     |  22 ++++-
>  drivers/bus/mhi/core/internal.h |  12 +++
>  drivers/bus/mhi/core/main.c     | 190 ++++++++++++++++++++++++----------------
>  include/linux/mhi.h             |  18 +++-
>  4 files changed, 162 insertions(+), 80 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hugo Mills <hugo@carfax.org.uk>
Subject: Re: your mail
Date: Tue, 20 Sep 2011 16:35:40 +0100
Message-ID: <20110920153540.GE21530@carfax.org.uk>
References: <c627c52800e0bb4e7884aa7174cb4a18@www.jots.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gDGSpKKIBgtShtf+"
Cc: linux-btrfs@vger.kernel.org
To: File's@jots.org, checksum?@jots.org
Return-path: <linux-btrfs-owner@vger.kernel.org>
In-Reply-To: <c627c52800e0bb4e7884aa7174cb4a18@www.jots.org>
List-ID: <linux-btrfs.vger.kernel.org>


--gDGSpKKIBgtShtf+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> Just wondering if/how one goes about getting the btrfs checksum of a given
> file.  Is there a way?

   Checksums are computed on individual 4k blocks, not on the whole
file. There's no explicit interface for retrieving checksums, but if
you understand the data structures, you can get hold of the checksums
for a file using the BTRFS_IOC_TREE_SEARCH ioctl.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- "How deep will this sub go?" "Oh,  she'll go all the way to ---   
                    the bottom if we don't stop her."                    

--gDGSpKKIBgtShtf+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD4DBQFOeLLMIKyzvlFcI40RAvBKAJ9yq7BDY1w4CZAFye1M3LyZgq6jfACWM9r/
oGQo2BAaMYJqHd9TcbFIgg==
=U+K1
-----END PGP SIGNATURE-----

--gDGSpKKIBgtShtf+--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hugo Mills <hugo@carfax.org.uk>
Subject: Re: your mail
Date: Tue, 20 Sep 2011 16:40:13 +0100
Message-ID: <20110920154013.GF21530@carfax.org.uk>
References: <c627c52800e0bb4e7884aa7174cb4a18@www.jots.org>
 <20110920153540.GE21530@carfax.org.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="E7i4zwmWs5DOuDSH"
To: linux-btrfs@vger.kernel.org, Ken D'Ambrosio <ken@jots.org>
Return-path: <linux-btrfs-owner@vger.kernel.org>
In-Reply-To: <20110920153540.GE21530@carfax.org.uk>
List-ID: <linux-btrfs.vger.kernel.org>


--E7i4zwmWs5DOuDSH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

   [Your Reply-to: header was screwed up, so I'm sending this again.

=46rom: Ken D'Ambrosio <ken@jots.org>
Reply-to: File's@jots.org, checksum?@jots.org

]

On Tue, Sep 20, 2011 at 04:35:40PM +0100, Hugo Mills wrote:
> On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> > Just wondering if/how one goes about getting the btrfs checksum of a gi=
ven
> > file.  Is there a way?
>=20
>    Checksums are computed on individual 4k blocks, not on the whole
> file. There's no explicit interface for retrieving checksums, but if
> you understand the data structures, you can get hold of the checksums
> for a file using the BTRFS_IOC_TREE_SEARCH ioctl.
>=20
>    Hugo.
>=20

--=20
=3D=3D=3D Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk=
 =3D=3D=3D
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- "How deep will this sub go?" "Oh,  she'll go all the way to ---  =20
                    the bottom if we don't stop her."                   =20

--E7i4zwmWs5DOuDSH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFOeLPdIKyzvlFcI40RAhiLAKCT5J/sx1RpyPSD60XQNnpuc1y6GwCghOxy
psV45hFf6p0heVUgf3tUSYA=
=2ccW
-----END PGP SIGNATURE-----

--E7i4zwmWs5DOuDSH--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Sterba <dave@jikos.cz>
Subject: Re: your mail
Date: Thu, 1 Mar 2012 13:58:14 +0100
Message-ID: <20120301125814.GA4334@twin.jikos.cz>
References: <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com> <1330605662.98275.YahooMailNeo@web30706.mail.mud.yahoo.com>
Reply-To: dave@jikos.cz
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"chris.mason@oracle.com" <chris.mason@oracle.com>
To: bella tk <enat_love1@yahoo.com>
Return-path: <linux-btrfs-owner@vger.kernel.org>
In-Reply-To: <1330605662.98275.YahooMailNeo@web30706.mail.mud.yahoo.com>
List-ID: <linux-btrfs.vger.kernel.org>

On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> I want to use btrfs defrag tool but before that i want to know how
> much the disk is fragmented. I have tried to use filefrag but it gives
> me FIBMAP:invalid argument for many times.

The only way to trigger FIBMAP on btrfs is to run filefrag with -B
option, but it should use FIEMAP by default and it works. With -v option
it'll list all extents.

> I am using e2fsprogs version 1.42 on debian squeeze. Is there another
> way to find out the level of fragmentation on btrfs filesystem?

For while filesystem fragmentation, you can use the btrfs-filefrags
too that Arne sent to the list some time ago.

If you're interested in file level fragmentation, then filefrag is the
tool to use, but beware that just counting extents is not enough, and
compression makes things more complicated to interpret results
correctly.

Also, defragmentation does unCOW the files (until the snapshot aware
defrag is finished).


david

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Mason <chris.mason@oracle.com>
Subject: Re: your mail
Date: Thu, 1 Mar 2012 09:26:25 -0500
Message-ID: <20120301142625.GW5054@shiny>
References: <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com>
 <1330605662.98275.YahooMailNeo@web30706.mail.mud.yahoo.com>
 <20120301125814.GA4334@twin.jikos.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: bella tk <enat_love1@yahoo.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Return-path: <linux-btrfs-owner@vger.kernel.org>
In-Reply-To: <20120301125814.GA4334@twin.jikos.cz>
List-ID: <linux-btrfs.vger.kernel.org>

On Thu, Mar 01, 2012 at 01:58:14PM +0100, David Sterba wrote:
> On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> > I want to use btrfs defrag tool but before that i want to know how
> > much the disk is fragmented. I have tried to use filefrag but it gives
> > me FIBMAP:invalid argument for many times.
> 
> The only way to trigger FIBMAP on btrfs is to run filefrag with -B
> option, but it should use FIEMAP by default and it works. With -v option
> it'll list all extents.

We actually disabled bmap to keep the swap code from remembering fixed
offsets for btrfs files.  The only way to get the mapping is with
fiemap.

The defrag ioctl won't bother defragging files that are not fragmented.

-chris

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from smtprelay06.ispgateway.de ([80.67.31.101]:34487 "EHLO
        smtprelay06.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754814AbcIAHug (ORCPT
        <rfc822;linux-btrfs@vger.kernel.org>); Thu, 1 Sep 2016 03:50:36 -0400
Received: from [77.13.68.6] (helo=hermione.invalid)
        by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256)
        (Exim 4.84)
        (envelope-from <envelope@m-berberich.de>)
        id 1bfMfX-0000RT-Pf
        for linux-btrfs@vger.kernel.org; Thu, 01 Sep 2016 09:44:15 +0200
Received: from berberic by hermione.invalid with local (Exim 4.87)
        (envelope-from <envelope@m-berberich.de>)
        id 1bfMfX-0002Wa-9K
        for linux-btrfs@vger.kernel.org; Thu, 01 Sep 2016 09:44:15 +0200
Date: Thu, 1 Sep 2016 09:44:15 +0200
From: M G Berberich <btrfs@oss.m-berberich.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: your mail
Message-ID: <20160901074415.pz32d72d4h6pk77t@invalid>
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

Am Mittwoch, den 31. August schrieb Fennec Fox:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
> 
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
> GlobalReserve, single: total=144.00MiB, used=0.00B
> 
> {02:50} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> Sorry, try again.
> [sudo] password for fennectech:
> /: 99.8 GiB (107167244288 bytes) trimmed
> 
> {03:08} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> /: 99.9 GiB (107262181376 bytes) trimmed
> 
>   I ran these commands minutes after echother ane each time it is
> trimming the entire free space
> 
> Anyone else seen this?   the filesystem is the root FS and is compressed

You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/sda2        96G   61G   33G  66% /


	MfG
	bmg

-- 
âDes is vĂśllig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!â          | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from mail-it0-f51.google.com ([209.85.214.51]:36228 "EHLO
        mail-it0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755163AbcIALRr (ORCPT
        <rfc822;linux-btrfs@vger.kernel.org>); Thu, 1 Sep 2016 07:17:47 -0400
Received: by mail-it0-f51.google.com with SMTP id i184so61065343itf.1
        for <linux-btrfs@vger.kernel.org>; Thu, 01 Sep 2016 04:17:46 -0700 (PDT)
Received: from [191.9.212.201] (rrcs-70-62-41-24.central.biz.rr.com. [70.62.41.24])
        by smtp.gmail.com with ESMTPSA id 15sm8593439itl.0.2016.09.01.04.17.44
        for <linux-btrfs@vger.kernel.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 01 Sep 2016 04:17:44 -0700 (PDT)
Subject: Re: your mail
To: linux-btrfs@vger.kernel.org
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Message-ID: <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
Date: Thu, 1 Sep 2016 07:17:38 -0400
MIME-Version: 1.0
In-Reply-To: <20160901074415.pz32d72d4h6pk77t@invalid>
Content-Type: text/plain; charset=utf-8; format=flowed
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

On 2016-09-01 03:44, M G Berberich wrote:
> Am Mittwoch, den 31. August schrieb Fennec Fox:
>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
>> 2016 x86_64 GNU/Linux
>> btrfs-progs v4.7
>>
>> Data, single: total=30.01GiB, used=18.95GiB
>> System, single: total=4.00MiB, used=16.00KiB
>> Metadata, single: total=1.01GiB, used=422.17MiB
>> GlobalReserve, single: total=144.00MiB, used=0.00B
>>
>> {02:50} Wed Aug 31
>> [fennectech@Titanium ~]$  sudo fstrim -v /
>> [sudo] password for fennectech:
>> Sorry, try again.
>> [sudo] password for fennectech:
>> /: 99.8 GiB (107167244288 bytes) trimmed
>>
>> {03:08} Wed Aug 31
>> [fennectech@Titanium ~]$  sudo fstrim -v /
>> [sudo] password for fennectech:
>> /: 99.9 GiB (107262181376 bytes) trimmed
>>
>>   I ran these commands minutes after echother ane each time it is
>> trimming the entire free space
>>
>> Anyone else seen this?   the filesystem is the root FS and is compressed
>
> You should be very happy that it is trimming at all. Typical situation
> on a used btrfs is
>
>   # fstrim -v /
>   /: 0 B (0 bytes) trimmed
>
> even if there is 33G unused space ob the fs:
>
>   # df -h /
>   Filesystem      Size  Used Avail Use% Mounted on
>   /dev/sda2        96G   61G   33G  66% /
>
I think you're using an old kernel, this has been working since at least 
4.5, but was broken in some older releases.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from blu004-omc1s32.hotmail.com ([65.55.116.43]:58142 "EHLO
        BLU004-OMC1S32.hotmail.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1753230AbcIAU5d (ORCPT
        <rfc822;linux-btrfs@vger.kernel.org>);
        Thu, 1 Sep 2016 16:57:33 -0400
From: Kyle Gates <kylegates@live.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: your mail
Date: Thu, 1 Sep 2016 16:44:36 +0000
Message-ID: <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>,<31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
In-Reply-To: <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
> Sent: Thursday, September 01, 2016 6:18 AM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: your mail
> 
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> >> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> UTC
> >> 2016 x86_64 GNU/Linux
> >> btrfs-progs v4.7
> >>
> >> Data, single: total=30.01GiB, used=18.95GiB System, single:
> >> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
> >> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
> >>
> >> {02:50} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> Sorry, try again.
> >> [sudo] password for fennectech:
> >> /: 99.8 GiB (107167244288 bytes) trimmed
> >>
> >> {03:08} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> /: 99.9 GiB (107262181376 bytes) trimmed
> >>
> >>   I ran these commands minutes after echother ane each time it is
> >> trimming the entire free space
> >>
> >> Anyone else seen this?   the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> >   # df -h /
> >   Filesystem      Size  Used Avail Use% Mounted on
> >   /dev/sda2        96G   61G   33G  66% /
> >
> I think you're using an old kernel, this has been working since at least 4.5, but
> was broken in some older releases.

M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.

On my system all space has been allocated on my root filesystem so 0 B are trimmed:
kyle@home:~$  uname -a
Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
kyle@home:~$  sudo btrfs fi show /
Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
        Total devices 2 FS bytes used 13.44GiB
        devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
        devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
kyle@home:~$  btrfs fi df /
Data, RAID1: total=18.97GiB, used=12.98GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=473.83MiB
GlobalReserve, single: total=160.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /
[sudo] password for kyle:
/: 0 B (0 bytes) trimmed

But I do have space trimmed on my home filesystem:
kyle@home:~$  sudo btrfs fi show /home/
Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
        Total devices 2 FS bytes used 18.63GiB
        devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
        devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
kyle@home:~$  btrfs fi df /home/
Data, RAID1: total=27.00GiB, used=18.46GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=2.00GiB, used=168.62MiB
GlobalReserve, single: total=64.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /home
/home: 70 GiB (75092721664 bytes) trimmed

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from smtprelay04.ispgateway.de ([80.67.31.31]:43008 "EHLO
        smtprelay04.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753032AbcIAVPY (ORCPT
        <rfc822;linux-btrfs@vger.kernel.org>); Thu, 1 Sep 2016 17:15:24 -0400
Received: from [77.13.67.237] (helo=hermione.invalid)
        by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256)
        (Exim 4.84)
        (envelope-from <envelope@m-berberich.de>)
        id 1bfZKR-0002YO-1q
        for linux-btrfs@vger.kernel.org; Thu, 01 Sep 2016 23:15:19 +0200
Received: from berberic by hermione.invalid with local (Exim 4.87)
        (envelope-from <envelope@m-berberich.de>)
        id 1bfZKQ-0001TV-IP
        for linux-btrfs@vger.kernel.org; Thu, 01 Sep 2016 23:15:18 +0200
Date: Thu, 1 Sep 2016 23:15:18 +0200
From: M G Berberich <btrfs@oss.m-berberich.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: your mail
Message-ID: <20160901211518.jk5tpmwnhbb22xf4@invalid>
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>
 <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

Am Donnerstag, den 01. September schrieb Austin S. Hemmelgarn:
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> > > 2016 x86_64 GNU/Linux
> > > btrfs-progs v4.7
> > > 
> > > Data, single: total=30.01GiB, used=18.95GiB
> > > System, single: total=4.00MiB, used=16.00KiB
> > > Metadata, single: total=1.01GiB, used=422.17MiB
> > > GlobalReserve, single: total=144.00MiB, used=0.00B
> > > 
> > > {02:50} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > Sorry, try again.
> > > [sudo] password for fennectech:
> > > /: 99.8 GiB (107167244288 bytes) trimmed
> > > 
> > > {03:08} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > /: 99.9 GiB (107262181376 bytes) trimmed
> > > 
> > >   I ran these commands minutes after echother ane each time it is
> > > trimming the entire free space
> > > 
> > > Anyone else seen this?   the filesystem is the root FS and is compressed
> > 
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> > 
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> > 
> > even if there is 33G unused space ob the fs:
> > 
> >   # df -h /
> >   Filesystem      Size  Used Avail Use% Mounted on
> >   /dev/sda2        96G   61G   33G  66% /
> > 
> I think you're using an old kernel, this has been working since at least
> 4.5, but was broken in some older releases.

No, Iâm always running a fairly up-to-date vanilla kernel on this
system. At the moment itâs:

  Linux hermione 4.7.2 #4 SMP PREEMPT Wed Aug 24 17:12:03 CEST 2016 x86_64 GNU/Linux

Iâm running kernels âĽ 4.5.0 since about April and I first reported this
problem at 7 Jul 2016 (Subject: fstrim problem/bug) probably with a
4.6.3 kernel.

	MfG
	bmg

-- 
âDes is vĂśllig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!â          | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:38985 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750992AbcIBCEH (ORCPT <rfc822;linux-btrfs@vger.kernel.org>);
        Thu, 1 Sep 2016 22:04:07 -0400
Subject: Re: your mail
To: Kyle Gates <kylegates@live.com>,
        "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>
 <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
 <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
From: Jeff Mahoney <jeffm@suse.com>
Message-ID: <2c480ed1-dc46-2756-1e05-380d6dd3e0f9@suse.com>
Date: Thu, 1 Sep 2016 21:51:25 -0400
MIME-Version: 1.0
In-Reply-To: <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="VD5AQaNJWXLe5ueXS4gRTh126iQX4quuk"
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--VD5AQaNJWXLe5ueXS4gRTh126iQX4quuk
Content-Type: multipart/mixed; boundary="14OlQosvoVxAmogV9xiWS3KpOsluMm2Ki";
 protected-headers="v1"
From: Jeff Mahoney <jeffm@suse.com>
To: Kyle Gates <kylegates@live.com>,
 "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
 "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Message-ID: <2c480ed1-dc46-2756-1e05-380d6dd3e0f9@suse.com>
Subject: Re: your mail
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>
 <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
 <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
In-Reply-To: <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>

--14OlQosvoVxAmogV9xiWS3KpOsluMm2Ki
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 9/1/16 12:44 PM, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=3D30.01GiB, used=3D18.95GiB System, single:
>>>> total=3D4.00MiB, used=3D16.00KiB Metadata, single: total=3D1.01GiB,
>>>> used=3D422.17MiB GlobalReserve, single: total=3D144.00MiB, used=3D0.=
00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>>   I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this?   the filesystem is the root FS and is compre=
ssed
>>>
>>> You should be very happy that it is trimming at all. Typical situatio=
n
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem      Size  Used Avail Use% Mounted on
>>>   /dev/sda2        96G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at lea=
st 4.5, but
>> was broken in some older releases.
>=20
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fs=
trim will only work on unallocated space.

Historically it was the opposite problem.  My fixes made it so it would
work on unallocated space.  We probably need some debugging to see why
it's not discarding extents that are allocated as block groups but
unallocated within them.

-Jeff

> On my system all space has been allocated on my root filesystem so 0 B =
are trimmed:
> kyle@home:~$  uname -a
> Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 U=
TC 2016 x86_64 x86_64 x86_64 GNU/Linux
> kyle@home:~$  sudo btrfs fi show /
> Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
>         Total devices 2 FS bytes used 13.44GiB
>         devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
>         devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
> kyle@home:~$  btrfs fi df /
> Data, RAID1: total=3D18.97GiB, used=3D12.98GiB
> System, RAID1: total=3D32.00MiB, used=3D16.00KiB
> Metadata, RAID1: total=3D1.00GiB, used=3D473.83MiB
> GlobalReserve, single: total=3D160.00MiB, used=3D0.00B
> kyle@home:~$  sudo fstrim -v /
> [sudo] password for kyle:
> /: 0 B (0 bytes) trimmed
>=20
> But I do have space trimmed on my home filesystem:
> kyle@home:~$  sudo btrfs fi show /home/
> Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
>         Total devices 2 FS bytes used 18.63GiB
>         devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
>         devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
> kyle@home:~$  btrfs fi df /home/
> Data, RAID1: total=3D27.00GiB, used=3D18.46GiB
> System, RAID1: total=3D32.00MiB, used=3D16.00KiB
> Metadata, RAID1: total=3D2.00GiB, used=3D168.62MiB
> GlobalReserve, single: total=3D64.00MiB, used=3D0.00B
> kyle@home:~$  sudo fstrim -v /home
> /home: 70 GiB (75092721664 bytes) trimmed
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>=20


--=20
Jeff Mahoney
SUSE Labs


--14OlQosvoVxAmogV9xiWS3KpOsluMm2Ki--

--VD5AQaNJWXLe5ueXS4gRTh126iQX4quuk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJXyNskAAoJEB57S2MheeWyOv0P/ROLnM6BtHG+6Ye360UWEdhp
0PBCITPgMJ6foay9dj0FXp00g7FbqJtwRySsfMNXnvB16S/naYv6Og2bPGIsigOU
ISjLLEz0vC3gZIoL0kh7+MUJL5rYX++rDFoTRIH0muUZZjCq/rVBb93Yewywh78P
adzTAu2aX8Dd419RGo5t91YMZpHSHzdRTTyxB/WD2S9QLnz0p2Z+6AtlyIi10TpY
gGxl/FJXE4lqr7TrukdyyEe44mZJVstJk8y7oESdPC6uB3niCeLWsdRos2pwM2KD
mXmP3vt31BvIVgtxnyFFgNRAV0sMasYKR5q1RZ7jVKpY24uC/Mb5mmsMYtM6A8kU
8OV529TbEesgh5PRusqUviWEjKP/hgG+jQv/ucvt4MnaNhYZYiQE09XXlai0R9hy
bv6DVZSI92kARTCxAGjbsexhTvbGttRHn+AB0ihdfeceHI57LR704E0NNPy4O3q/
YClDyFE5IGR5VM/uINmPX3LZ4VxDQQn6hmQEI2I3oSDSBxdDdvhdVWA7M8VHoOEu
HZzek+q59OR0AapjE1aLDdMpQVeQcXDeE0gyVKFtwnBOkayD3Lm/3x7FESg2YyW0
dAsYsEozji7sLjMo2wRmBpbyYvh1QHDvH01v6YEIfN7NrvrNThbeATdE13luuchw
Su17rCdOy5K4tWk+BPmX
=tAyk
-----END PGP SIGNATURE-----

--VD5AQaNJWXLe5ueXS4gRTh126iQX4quuk--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from mail-oi0-f44.google.com ([209.85.218.44]:33641 "EHLO
        mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753563AbcIBPEl (ORCPT
        <rfc822;linux-btrfs@vger.kernel.org>); Fri, 2 Sep 2016 11:04:41 -0400
Received: by mail-oi0-f44.google.com with SMTP id c15so165216457oig.0
        for <linux-btrfs@vger.kernel.org>; Fri, 02 Sep 2016 08:04:41 -0700 (PDT)
Subject: Re: your mail
To: Kyle Gates <kylegates@live.com>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
References: <CAD1x5BA5k9MUdzT-s0kzFfb5+idoJSFaOux0xQS-jd_D0HTDWA@mail.gmail.com>
 <20160901074415.pz32d72d4h6pk77t@invalid>
 <31a75b1a-445a-47cd-816e-1e7e9d1c4bb8@gmail.com>
 <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Message-ID: <34ee2549-1cf4-cfb3-6818-a342aa9d27d2@gmail.com>
Date: Thu, 1 Sep 2016 13:06:14 -0400
MIME-Version: 1.0
In-Reply-To: <CY4PR06MB2726B15A26AA728457B155B9B0E20@CY4PR06MB2726.namprd06.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

On 2016-09-01 12:44, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>>   I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this?   the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem      Size  Used Avail Use% Mounted on
>>>   /dev/sda2        96G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at least 4.5, but
>> was broken in some older releases.
>
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.
Yep, that would do so also, and this behavior really could be much 
better documented.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from pepin.polanet.pl ([193.34.52.2]:52720 "EHLO pepin.polanet.pl"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751238AbeBRJ2D (ORCPT <rfc822;linux-btrfs@vger.kernel.org>);
        Sun, 18 Feb 2018 04:28:03 -0500
Date: Sun, 18 Feb 2018 10:28:02 +0100
From: Tomasz Pala <gotar@polanet.pl>
To: Tomasz =?iso-8859-2?Q?K=B3oczko?= <kloczko.tomasz@gmail.com>
Cc: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20180218092802.GA25085@polanet.pl>
References: <CABB28Cw2+jYynXk1e+Lbx+4otsj5BLXucVV6W3+kvm3RDbH_AQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
In-Reply-To: <CABB28Cw2+jYynXk1e+Lbx+4otsj5BLXucVV6W3+kvm3RDbH_AQ@mail.gmail.com>
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

On Sun, Feb 18, 2018 at 08:14:25 +0000, Tomasz Kłoczko wrote:

> For some reasons btrfs pool each volume is not displayed in mount and
> df output, and I cannot find how to display volumes/snapshots usage
> using btrfs command.

In general: not possible without enabling quotas, which in turn impact
snapshot performance significally.

btrfs quota enable /
btrfs quota rescan /
btrfs qgroup sh --sort=excl /

> So now I have many volumes and snapshots in my home directory, but to
> maintain all this I must use root permission. As non-root working in
> my own home which is separated btrfs volume it would be nice to have
> the possibility to delegate permission to create, destroy,
> send/receive, mount/umount etc. snapshots, volumes like it os possible
> on zfs.

I've already noticed this problem on February 10th:
[btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks

In short: not possible. Regular user can only create subvolumes.

> BTW: someone maybe started working on something like .zfs hidden
> directory functions which is in each zfs volume mountpoint?

In btrfs world this is done differently - don't put main (working) volume in the
root, but mount some branch by default, keeping all the subvolumes next
to it. I.e. don't:

@working_subvolume
@working_subvolume/snapshots

but:

@root_of_the_fs
@root_of_the_fs/working_subvolume
@root_of_the_fs/snapshots

In fact this is manual workaroud for the problem you've mentioned.

> Have few or few tenths snapshots is not so big deal but the same on
> scale few hundreds, thousands or more snapshots I think that would be
> really hard without something like hidden .btrfs/snapshots directory.

With few hundreds of subvolumes btrfs would fail miserably.

> After few years not using btrfs (because previously was quite
> unstable) It is really good to see that now I'm not able to crash it.

It's not crashing with LTS 4.4 and 4.9 kernels, many reports of various
crashes in 4.12, 4.14 and 4.15 were posted here. It is really hard to say,
which of the post-4.9 kernels have reliable btrfs.

-- 
Tomasz Pala <gotar@pld-linux.org>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-btrfs-owner@vger.kernel.org>
Received: from pepin.polanet.pl ([193.34.52.2]:52913 "EHLO pepin.polanet.pl"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751238AbeBRJe4 (ORCPT <rfc822;linux-btrfs@vger.kernel.org>);
        Sun, 18 Feb 2018 04:34:56 -0500
Date: Sun, 18 Feb 2018 10:34:55 +0100
From: Tomasz Pala <gotar@polanet.pl>
To: Tomasz =?iso-8859-2?Q?K=B3oczko?= <kloczko.tomasz@gmail.com>
Cc: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20180218093454.GA13420@polanet.pl>
References: <CABB28Cw2+jYynXk1e+Lbx+4otsj5BLXucVV6W3+kvm3RDbH_AQ@mail.gmail.com>
 <20180218092802.GA25085@polanet.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
In-Reply-To: <20180218092802.GA25085@polanet.pl>
Sender: linux-btrfs-owner@vger.kernel.org
List-ID: <linux-btrfs.vger.kernel.org>

On Sun, Feb 18, 2018 at 10:28:02 +0100, Tomasz Pala wrote:

> I've already noticed this problem on February 10th:
> [btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks
> 
> In short: not possible. Regular user can only create subvolumes.

Not possible "oficially". Axel Burri has replied with more helpful approach:
https://github.com/digint/btrfs-progs-btrbk

Unfortunately this issue was not picked up by any developer, so for now
we can only wait for splitting libbtrfsutil so this task could be easier.

-- 
Tomasz Pala <gotar@pld-linux.org>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Greg KH <greg@kroah.com>
Subject: Re: your mail
Date: Wed, 18 May 2011 12:22:12 -0700
Message-ID: <20110518192212.GC26945@kroah.com>
References: <4DD305B3.3000707@am.sony.com>
 <1305744925-8162-1-git-send-email-abogani@kernel.org>
Mime-Version: 1.0
Return-path: <linux-kernel-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=gSZSo83GeqXHefKDuVk7tX5gczU=; b=Rs6WI8iIbWyAdjE6LNAwj4A2NddIXe1wmLavZ5NbjR1oNI6/yGcFKJHnZK5LaZLIBTtPC2rNPl6KmMwyGmaU6SYH4CqZoO/d8e0PAjdgzOR5vWkMaNtVkAu3jmWAMerk0ptQm4fvTV8KK7+sGdVceJt97wk74fTtEKueNopY7aA=
Content-Disposition: inline
In-Reply-To: <1305744925-8162-1-git-send-email-abogani@kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-embedded.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Alessio Igor Bogani <abogani@kernel.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Tim Bird <tim.bird@am.sony.com>, Christoph Hellwig <hch@infradead.org>, Anders Kaseorg <andersk@ksplice.com>, Tim Abbott <tabbott@ksplice.com>, LKML <linux-kernel@vger.kernel.org>, Linux Embedded <linux-embedded@vger.kernel.org>, Jason Wessel <jason.wessel@windriver.com>, Dirk Behme <dirk.behme@googlemail.com>

On Wed, May 18, 2011 at 08:55:25PM +0200, Alessio Igor Bogani wrote:
> Dear Mr. Bird, Dear Mr. Kroah-Hartman,
> 
> Sorry for my very bad English.
> 
> 2011/5/18 Tim Bird <tim.bird@am.sony.com>:
> [...]
> > Alessio - do you have any timings you can share for the speedup?
> 
> You can find a little benchmark using ftrace at end of this email:
> https://lkml.org/lkml/2011/4/5/341
> 
> > On 05/17/2011 04:22 PM, Greg KH wrote:
> >> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
> >>> This work was supported by a hardware donation from the CE Linux Forum.
> [...]
> >> Please explain why you make a change, not just who sponsored the change,
> >> that's not very interesting to developers.
> 
> You are right. I apologize.
> 
> This patch is a missing piece (not essential it is only a further little
> optimization) of this little patchset:
> https://lkml.org/lkml/2011/4/16/48
> 
> Unfortunately I forgot to include this patch in the series (my first error)
> then I avoided explaining the changes because I had thought that those were
> already enough explained in the cover-letter of the patchset (my second error).
> 
> Sorry for my mistakes.
> 
> Is this better?
> 
> Subject: [PATCH] module: Use binary search in lookup_symbol()
> 
> The function is_exported() with its helper function lookup_symbol() are used to
> verify if a provided symbol is effectively exported by the kernel or by the
> modules. Now that both have their symbols sorted we can replace a linear search
> with a binary search which provide a considerably speed-up.
> 
> This work was supported by a hardware donation from the CE Linux Forum.
> 
> Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>

Much better, I have no objection to this at all.

	Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

Care to resend it without all the stuff above so someone (Rusty I guess)
can apply it?

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alessio Igor Bogani <abogani@kernel.org>
Subject: Re: your mail
Date: Wed, 18 May 2011 22:35:31 +0200
Message-ID: <BANLkTim2DBkrFbdR=0a=wGqFPX1O7d+C7g@mail.gmail.com>
References: <4DD305B3.3000707@am.sony.com>
	<1305744925-8162-1-git-send-email-abogani@kernel.org>
	<20110518192212.GC26945@kroah.com>
Mime-Version: 1.0
Return-path: <linux-kernel-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        bh=73KgZ6IQOMTQC8mkHqsRjPQGDIVQdcI0L9bvXvNeNH4=;
        b=soZAYPTuMbgIdaJFsaA7SiY78fBOgDwUad2v32aejy5XN7vEk1vaVvjNnxKtOWxCwB
         pEk86G9Nk3AyRh3Iw3Rw76CFZgbejxgi7KW57T61urRxzbTPmFXQ0a1HcsoMiZXC3kWF
         v7TD7RNa8F8WeA+8j9dhheWbIYjQSOhDzaSms=
In-Reply-To: <20110518192212.GC26945@kroah.com>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-embedded.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Greg KH <greg@kroah.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Tim Bird <tim.bird@am.sony.com>, Christoph Hellwig <hch@infradead.org>, Anders Kaseorg <andersk@ksplice.com>, Tim Abbott <tabbott@ksplice.com>, LKML <linux-kernel@vger.kernel.org>, Linux Embedded <linux-embedded@vger.kernel.org>, Jason Wessel <jason.wessel@windriver.com>, Dirk Behme <dirk.behme@googlemail.com>

Dear Mr. Kroah-Hartman,

2011/5/18 Greg KH <greg@kroah.com>:
[...]
> Care to resend it without all the stuff above so someone (Rusty I guess)
> can apply it?

Sure! It'll follow in few minutes.

Thank you very much!

Ciao,
Alessio

From mboxrd@z Thu Jan  1 00:00:00 1970
From: tytso@mit.edu
Subject: Re: your mail
Date: Fri, 14 May 2010 18:07:26 -0400
Message-ID: <20100514220726.GF16989@thunk.org>
References: <20100514213946.0FEA81BC316@ruihe.smo.corp.google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: curtw@google.com, fmayhar@google.com, mrubin@google.com,
	linux-ext4@vger.kernel.org
To: Jiaying Zhang <jiayingz@google.com>
Return-path: <linux-ext4-owner@vger.kernel.org>
Received: from thunk.org ([69.25.196.29]:34276 "EHLO thunker.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752780Ab0ENWHa (ORCPT <rfc822;linux-ext4@vger.kernel.org>);
	Fri, 14 May 2010 18:07:30 -0400
Content-Disposition: inline
In-Reply-To: <20100514213946.0FEA81BC316@ruihe.smo.corp.google.com>
Sender: linux-ext4-owner@vger.kernel.org
List-ID: <linux-ext4.vger.kernel.org>

On Fri, May 14, 2010 at 02:39:45PM -0700, Jiaying Zhang wrote:
> This patch changes e2fsck to use the same checking on the validity
> of an extent as the kernel ext4 is using.

Actually, the better fix is to explicitly test for extent.e_blk == 0.
The kernel test works because at the moment nothing creates file
systems where s_first_data_block is anything other than 0 or 1.  But
technically speaking, having an extent which begins at
s_first_data_block isn't actually _wrong_.  It might overlap with fs
metadata, but pass1b will handle that.  The reason why it doesn't in
the case of 0 is because 0 is a special case and also means "there's
no block present" when returned by ext2fs_block_iterate.

Arguably the kernel should be changed to something similar, but in
practice it won't make a difference in practice.  E2fsck can do a
slightly better job recovering in the case of 1k block filesystems, so
this patch is slightly better.

						- Ted

commit e6238d3708d328851bfdff7580d1b8504c7cf2e4
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri May 14 18:03:14 2010 -0400

    e2fsck: Explicitly reject extents that begin at physical block 0 as illegal
    
    In the case where s_first_data_block is 1, we need to explictly reject
    an extent whose starting physical block is zero.
    
    Thanks to Jiaying Zhang <jiayingz@google.com> for finding this bug.
    
    Addresses-Google-Bug: #2573806
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 5e2ecc7..c35937f 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1694,7 +1694,8 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
 		is_dir = LINUX_S_ISDIR(pctx->inode->i_mode);
 
 		problem = 0;
-		if (extent.e_pblk < ctx->fs->super->s_first_data_block ||
+		if (extent.e_pblk == 0 ||
+		    extent.e_pblk < ctx->fs->super->s_first_data_block ||
 		    extent.e_pblk >= ctx->fs->super->s_blocks_count)
 			problem = PR_1_EXTENT_BAD_START_BLK;
 		else if (extent.e_lblk < start_block)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kara <jack@suse.cz>
Subject: Re: your mail
Date: Tue, 3 May 2011 15:46:36 +0200
Message-ID: <20110503134636.GA6009@quack.suse.cz>
References: <4DBFE09E.5070805@canonical.com>
 <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: jack@suse.cz, toshi.okajima@jp.fujitsu.com, tytso@mit.edu,
	m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: Surbhi Palande <surbhi.palande@canonical.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-ext4.vger.kernel.org

On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> Toshiyuki pointed out.
> 
> zap_pte_range()
>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)  
> 
> So, I think that it is here that we should do the checking for a ext4 F.S
> frozen state and also prevent a parallel ext4 F.S freeze from happening.
> 
> Attaching a patch for initial review. Please do let me know your thoughts! 
  This is definitely the wrong place. ->set_page_dirty() callbacks are
called with various locks held and the page need not be locked (thus
dereferencing page->mapping is oopsable). Moreover this particular callback
is called only in data=journal mode.

Believe me, the right place is page_mkwrite() - you have to catch the
read-only => read-write page transition. Once the page is mapped
read-write, you've already lost the race.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Surbhi Palande <surbhi.palande@canonical.com>
Subject: Re: your mail
Date: Tue, 03 May 2011 16:56:57 +0300
Message-ID: <4DC009A9.20308@canonical.com>
References: <4DBFE09E.5070805@canonical.com> <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com> <20110503134636.GA6009@quack.suse.cz>
Reply-To: surbhi.palande@canonical.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: toshi.okajima@jp.fujitsu.com, tytso@mit.edu,
	m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: Jan Kara <jack@suse.cz>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
In-Reply-To: <20110503134636.GA6009@quack.suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-ext4.vger.kernel.org

On 05/03/2011 04:46 PM, Jan Kara wrote:
> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:

Sorry for missing the subject line :(
>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>> Toshiyuki pointed out.
>>
>> zap_pte_range()
>>    mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>
>> So, I think that it is here that we should do the checking for a ext4 F.S
>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>
>> Attaching a patch for initial review. Please do let me know your thoughts!
>    This is definitely the wrong place. ->set_page_dirty() callbacks are
> called with various locks held and the page need not be locked (thus
> dereferencing page->mapping is oopsable). Moreover this particular callback
> is called only in data=journal mode.
Ok! Thanks for that!

>
> Believe me, the right place is page_mkwrite() - you have to catch the
> read-only =>  read-write page transition. Once the page is mapped
> read-write, you've already lost the race.

My only point is:
1) something should prevent the freeze from happening. We cant merely 
check the vfs_check_frozen()?

And this should be done where the page is marked dirty.Also, I thought 
that the page is marked read-write only in the page table in the 
__do_page_fault()? i.e the zap_pte_range() marks them dirty in the page 
cache? Is this understanding right?

IMHO, whatever code dirties the page in the page cache should call a F.S 
specific function and let it _prevent_ a fsfreeze while the page is 
getting dirtied, so that a freeze called after this point flushes this page!

Warm Regards,
Surbhi.










>
> 								Honza


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Surbhi Palande <surbhi.palande@canonical.com>
Subject: Re: your mail
Date: Tue, 03 May 2011 18:26:08 +0300
Message-ID: <4DC01E90.4070506@canonical.com>
References: <4DBFE09E.5070805@canonical.com> <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com> <20110503134636.GA6009@quack.suse.cz> <4DC009A9.20308@canonical.com>
Reply-To: surbhi.palande@canonical.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jan Kara <jack@suse.cz>, toshi.okajima@jp.fujitsu.com,
	tytso@mit.edu, m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: surbhi.palande@canonical.com
Return-path: <linux-fsdevel-owner@vger.kernel.org>
In-Reply-To: <4DC009A9.20308@canonical.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-ext4.vger.kernel.org

On 05/03/2011 04:56 PM, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>
> Sorry for missing the subject line :(
>>> On munmap() zap_pte_range() is called which dirties the PTE dirty
>>> pages as
>>> Toshiyuki pointed out.
>>>
>>> zap_pte_range()
>>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>
>>> So, I think that it is here that we should do the checking for a ext4
>>> F.S
>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>
>>> Attaching a patch for initial review. Please do let me know your
>>> thoughts!
>> This is definitely the wrong place. ->set_page_dirty() callbacks are
>> called with various locks held and the page need not be locked (thus
>> dereferencing page->mapping is oopsable). Moreover this particular
>> callback
>> is called only in data=journal mode.
> Ok! Thanks for that!
>
>>
>> Believe me, the right place is page_mkwrite() - you have to catch the
>> read-only => read-write page transition. Once the page is mapped
>> read-write, you've already lost the race.
Also, we then need to prevent a munmap()/zap_pte_range() call from 
dirtying a mmapped file page when the F.S is frozen?

Warm Regards,
Surbhi.

>
> My only point is:
> 1) something should prevent the freeze from happening. We cant merely
> check the vfs_check_frozen()?
>
> And this should be done where the page is marked dirty.Also, I thought
> that the page is marked read-write only in the page table in the
> __do_page_fault()? i.e the zap_pte_range() marks them dirty in the page
> cache? Is this understanding right?
>
> IMHO, whatever code dirties the page in the page cache should call a F.S
> specific function and let it _prevent_ a fsfreeze while the page is
> getting dirtied, so that a freeze called after this point flushes this
> page!
>
> Warm Regards,
> Surbhi.
>
>
>
>
>
>
>
>
>
>
>>
>> Honza
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kara <jack@suse.cz>
Subject: Re: your mail
Date: Tue, 3 May 2011 17:36:32 +0200
Message-ID: <20110503153632.GC6009@quack.suse.cz>
References: <4DBFE09E.5070805@canonical.com>
 <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com>
 <20110503134636.GA6009@quack.suse.cz>
 <4DC009A9.20308@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jan Kara <jack@suse.cz>, toshi.okajima@jp.fujitsu.com,
	tytso@mit.edu, m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: Surbhi Palande <surbhi.palande@canonical.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <4DC009A9.20308@canonical.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-ext4.vger.kernel.org

On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> 
> Sorry for missing the subject line :(
> >>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>Toshiyuki pointed out.
> >>
> >>zap_pte_range()
> >>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>
> >>So, I think that it is here that we should do the checking for a ext4 F.S
> >>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>
> >>Attaching a patch for initial review. Please do let me know your thoughts!
> >   This is definitely the wrong place. ->set_page_dirty() callbacks are
> >called with various locks held and the page need not be locked (thus
> >dereferencing page->mapping is oopsable). Moreover this particular callback
> >is called only in data=journal mode.
> Ok! Thanks for that!
> 
> >
> >Believe me, the right place is page_mkwrite() - you have to catch the
> >read-only =>  read-write page transition. Once the page is mapped
> >read-write, you've already lost the race.
> 
> My only point is:
> 1) something should prevent the freeze from happening. We cant
> merely check the vfs_check_frozen()?
  Yes, I agree - see my other email with patches.

> And this should be done where the page is marked dirty.Also, I
> thought that the page is marked read-write only in the page table in
> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> the page cache? Is this understanding right?
  The page can become dirty either because it was written via standard
write - write_begin is responsible for reliable check here - or it was
written via mmap - here we rely on page_mkwrite to do a reliable check -
it is analogous to write_begin callback. There should be no other way
to dirty a page.

With dirty bits it is a bit complicated. We have two of them in fact. One
in page table entry maintained by mmu and one in page structure maintained
by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
from page table into struct page. This is a lazy process so page can in
principle have new data without a dirty bit set in struct page because we
have not yet copied the dirty bit from page table. Only at moments where it
is important (like when we want to unmap the page, or throw away the page,
or so), we make sure struct page and page table bits are in sync.

Another subtle thing you need not be aware of it that when we clear page
dirty bit, we also writeprotect the page. So we are guaranteed to get a
page fault when the page is written to again.

> IMHO, whatever code dirties the page in the page cache should call a
> F.S specific function and let it _prevent_ a fsfreeze while the page
> is getting dirtied, so that a freeze called after this point flushes
> this page!
  Agreed, that's what code in write_begin() and page_mkwrite() should
achieve.
								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Surbhi Palande <surbhi.palande@canonical.com>
Subject: Re: your mail
Date: Tue, 03 May 2011 18:43:48 +0300
Message-ID: <4DC022B4.5030906@canonical.com>
References: <4DBFE09E.5070805@canonical.com> <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com> <20110503134636.GA6009@quack.suse.cz> <4DC009A9.20308@canonical.com> <20110503153632.GC6009@quack.suse.cz>
Reply-To: surbhi.palande@canonical.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: toshi.okajima@jp.fujitsu.com, tytso@mit.edu,
	m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: Jan Kara <jack@suse.cz>
Return-path: <linux-ext4-owner@vger.kernel.org>
Received: from adelie.canonical.com ([91.189.90.139]:53166 "EHLO
	adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751873Ab1ECPn5 (ORCPT
	<rfc822;linux-ext4@vger.kernel.org>); Tue, 3 May 2011 11:43:57 -0400
In-Reply-To: <20110503153632.GC6009@quack.suse.cz>
Sender: linux-ext4-owner@vger.kernel.org
List-ID: <linux-ext4.vger.kernel.org>

On 05/03/2011 06:36 PM, Jan Kara wrote:
> On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
>> On 05/03/2011 04:46 PM, Jan Kara wrote:
>>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>>
>> Sorry for missing the subject line :(
>>>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>>>> Toshiyuki pointed out.
>>>>
>>>> zap_pte_range()
>>>>    mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>>
>>>> So, I think that it is here that we should do the checking for a ext4 F.S
>>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>>
>>>> Attaching a patch for initial review. Please do let me know your thoughts!
>>>    This is definitely the wrong place. ->set_page_dirty() callbacks are
>>> called with various locks held and the page need not be locked (thus
>>> dereferencing page->mapping is oopsable). Moreover this particular callback
>>> is called only in data=journal mode.
>> Ok! Thanks for that!
>>
>>>
>>> Believe me, the right place is page_mkwrite() - you have to catch the
>>> read-only =>   read-write page transition. Once the page is mapped
>>> read-write, you've already lost the race.
>>
>> My only point is:
>> 1) something should prevent the freeze from happening. We cant
>> merely check the vfs_check_frozen()?
>    Yes, I agree - see my other email with patches.
>
>> And this should be done where the page is marked dirty.Also, I
>> thought that the page is marked read-write only in the page table in
>> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
>> the page cache? Is this understanding right?
>    The page can become dirty either because it was written via standard
> write - write_begin is responsible for reliable check here - or it was
> written via mmap - here we rely on page_mkwrite to do a reliable check -
> it is analogous to write_begin callback. There should be no other way
> to dirty a page.
>
> With dirty bits it is a bit complicated. We have two of them in fact. One
> in page table entry maintained by mmu and one in page structure maintained
> by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> from page table into struct page. This is a lazy process so page can in
> principle have new data without a dirty bit set in struct page because we
> have not yet copied the dirty bit from page table. Only at moments where it
> is important (like when we want to unmap the page, or throw away the page,
> or so), we make sure struct page and page table bits are in sync.
>
> Another subtle thing you need not be aware of it that when we clear page
> dirty bit, we also writeprotect the page. So we are guaranteed to get a
> page fault when the page is written to again.
>
>> IMHO, whatever code dirties the page in the page cache should call a
>> F.S specific function and let it _prevent_ a fsfreeze while the page
>> is getting dirtied, so that a freeze called after this point flushes
>> this page!
>    Agreed, that's what code in write_begin() and page_mkwrite() should
> achieve.
> 								Honza
Thanks a lot for the wonderful explanation :)

How about the revert : i.e calling  jbd2_journal_unlock_updates() from 
ext4_unfreeze() instead of the ext4_freeze()? Do you agree to that?


Warm Regards,
Surbhi.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kara <jack@suse.cz>
Subject: Re: your mail
Date: Wed, 4 May 2011 21:24:36 +0200
Message-ID: <20110504192436.GC6968@quack.suse.cz>
References: <4DBFE09E.5070805@canonical.com>
 <1304428117-6195-1-git-send-email-surbhi.palande@canonical.com>
 <20110503134636.GA6009@quack.suse.cz>
 <4DC009A9.20308@canonical.com>
 <20110503153632.GC6009@quack.suse.cz>
 <4DC022B4.5030906@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jan Kara <jack@suse.cz>, toshi.okajima@jp.fujitsu.com,
	tytso@mit.edu, m.mizuma@jp.fujitsu.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sandeen@redhat.com
To: Surbhi Palande <surbhi.palande@canonical.com>
Return-path: <linux-ext4-owner@vger.kernel.org>
Received: from cantor2.suse.de ([195.135.220.15]:32813 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754492Ab1EDTYj (ORCPT <rfc822;linux-ext4@vger.kernel.org>);
	Wed, 4 May 2011 15:24:39 -0400
Content-Disposition: inline
In-Reply-To: <4DC022B4.5030906@canonical.com>
Sender: linux-ext4-owner@vger.kernel.org
List-ID: <linux-ext4.vger.kernel.org>

On Tue 03-05-11 18:43:48, Surbhi Palande wrote:
> On 05/03/2011 06:36 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> >>On 05/03/2011 04:46 PM, Jan Kara wrote:
> >>>On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> >>
> >>Sorry for missing the subject line :(
> >>>>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>>>Toshiyuki pointed out.
> >>>>
> >>>>zap_pte_range()
> >>>>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>>>
> >>>>So, I think that it is here that we should do the checking for a ext4 F.S
> >>>>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>>>
> >>>>Attaching a patch for initial review. Please do let me know your thoughts!
> >>>   This is definitely the wrong place. ->set_page_dirty() callbacks are
> >>>called with various locks held and the page need not be locked (thus
> >>>dereferencing page->mapping is oopsable). Moreover this particular callback
> >>>is called only in data=journal mode.
> >>Ok! Thanks for that!
> >>
> >>>
> >>>Believe me, the right place is page_mkwrite() - you have to catch the
> >>>read-only =>   read-write page transition. Once the page is mapped
> >>>read-write, you've already lost the race.
> >>
> >>My only point is:
> >>1) something should prevent the freeze from happening. We cant
> >>merely check the vfs_check_frozen()?
> >   Yes, I agree - see my other email with patches.
> >
> >>And this should be done where the page is marked dirty.Also, I
> >>thought that the page is marked read-write only in the page table in
> >>the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> >>the page cache? Is this understanding right?
> >   The page can become dirty either because it was written via standard
> >write - write_begin is responsible for reliable check here - or it was
> >written via mmap - here we rely on page_mkwrite to do a reliable check -
> >it is analogous to write_begin callback. There should be no other way
> >to dirty a page.
> >
> >With dirty bits it is a bit complicated. We have two of them in fact. One
> >in page table entry maintained by mmu and one in page structure maintained
> >by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> >from page table into struct page. This is a lazy process so page can in
> >principle have new data without a dirty bit set in struct page because we
> >have not yet copied the dirty bit from page table. Only at moments where it
> >is important (like when we want to unmap the page, or throw away the page,
> >or so), we make sure struct page and page table bits are in sync.
> >
> >Another subtle thing you need not be aware of it that when we clear page
> >dirty bit, we also writeprotect the page. So we are guaranteed to get a
> >page fault when the page is written to again.
> >
> >>IMHO, whatever code dirties the page in the page cache should call a
> >>F.S specific function and let it _prevent_ a fsfreeze while the page
> >>is getting dirtied, so that a freeze called after this point flushes
> >>this page!
> >   Agreed, that's what code in write_begin() and page_mkwrite() should
> >achieve.
> >								Honza
> Thanks a lot for the wonderful explanation :)
> 
> How about the revert : i.e calling  jbd2_journal_unlock_updates()
> from ext4_unfreeze() instead of the ext4_freeze()? Do you agree to
> that?
  Sorry, I don't agree with revert. We could talk about changing
jbd2_journal_unlock_updates() to not return with mutex held (and handle
synchronization of locked journal operations differently) as an alternative
to doing "freeze" reference counting. But returning with mutex held to user
space is no-go. It will cause problems in lockdep, violates kernel locking
rules, and generally is a bad programming ;).

								Honza

-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC49727702;
	Wed, 26 Feb 2025 05:44:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1740548657; cv=fail; b=f9X0iax58JsY9f3y5ZqkXD8rH3xxgweHWPBKF4jB9UzMBH35dxaGYLWZwDX1Fle1/XiseFvXiW8TDnHOzEXgTNqTg35XetMqpnQvXmWE17TB2fAkbpsN30HsdaV1QhmFiOZd5eqlLTahWnrXWoWhLuHkCKI20D92js6zk4eSUpE=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1740548657; c=relaxed/simple;
	bh=KKUW1lgzxQDhKXyqwPh+UZwyAzUyTYTY7g1xl5FdBD0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
	 Content-Disposition:In-Reply-To:MIME-Version; b=ROeqjKNgwKyfQcOwgbFJ8SRmTm33hOb2qoDDFYvekMN+tSBTuHf3WBj9u+kmPP9W1WuTytHropHQNSYBQKCb4b6DWtk6KXrORw2S7sO3rnHUE8KZhW1yNKKrff857LP5m2e6S7234cWAXD77FSdvNwpSAGYQ6ykQgsMGANpcnHo=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=V+a8EvTz; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=ei02iFyQ; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="V+a8EvTz";
	dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="ei02iFyQ"
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
	by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 51Q5XcOe021158;
	Wed, 26 Feb 2025 05:42:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=EU7J3QE2ipP0j3joGRynHOfZJpoZRzZ7HPxdCAR/NNU=; b=
	V+a8EvTz80OGymCWWhcs5CXH6nQxCyNFxd2flxJWlKZxueu8MgEiCpVJamKgikhv
	6SKSgK3Pwp56uYi+G/EcRJvsga00OokngjueT0QB+y1UXp0acrAwsiU/TuYxL20s
	SB/tx+tI1yn439PvWupY4unpd3Mp4STqAg8vr53zUZnihu3QrU6rPi2M3HOFxUuk
	OpD2oaw1bt/Zyl4KnBnyi8/+qXSnCjvnrWPoJiL1FH8Eudc5sDzvCcTVfG/FIALe
	dB0a5nVX6WrbbrH0ozjbQjDQ99Tv2NXtBk0tr/WKGTq76uinXa4SjeX7yeZKHYgB
	RTalhy/s0GY3Tg4UCmgFAQ==
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
	by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 451psc8e8j-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Wed, 26 Feb 2025 05:42:58 +0000 (GMT)
Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
	by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 51Q4rexN007532;
	Wed, 26 Feb 2025 05:42:58 GMT
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2049.outbound.protection.outlook.com [104.47.70.49])
	by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 44y51g81ck-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Wed, 26 Feb 2025 05:42:58 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=m6snx7ehSCHMU8EEfVq+ZnsAGSS/GLniOVNPSu68AXv7eIRXfOrqEBKFCXC/Kh5Or3IJodw7Q/6/k939TFHEZfWdWKckDZHg2YF0RE79MFASaiDy7JWHH8+sRE12IC4maSmrGdR8WQ22OGVkpHUAK3xu7fDAlBywfAuH+RyEXCSdkohM40HQaGRt3CFw+SN7Ei9h+8w4Zx+cPYQClKIaF675yRtUll21P/6H2u7VzaE1stRMnXemxBkEeNcCZ9FHDjoewDP5q22C6TP1f++SG5rTNiJ9z0MuxgtW9CS8b1STUsiOKvdVAy3efSR2ajDslahLBJHPi1gnNTgY/+nHpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EU7J3QE2ipP0j3joGRynHOfZJpoZRzZ7HPxdCAR/NNU=;
 b=sMhRPJlWQkj0LRNbZ7tLMRbr4sn8gCIfC7jzLBVTsmNbwkKY560dQi7y12CEsdJNyh0K8iaZcYaDQNU2VbrcVlMHD6BhS7SBj990nYH6plPZvQ2tur72dAC6qZc/jtiYv3pBqykpsWz8vjfyN1TbWsmjrrIRkIv3T8YrV6I47oAv4pL+QvuifouxCb2lWf51K2Vsjdp78b5g0RrwSkT7wQKz2++aMwggoRcAPgt5Ea8yU4DYYb14oqSS0S24koNUfcHvgFvVOvAJEmwC+ugPfw5X7SvXXiBwtNZno87iJYxV6JkWNxdkQfzbPINK3b8nWdun4tGQkD561LYwhu9RfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=EU7J3QE2ipP0j3joGRynHOfZJpoZRzZ7HPxdCAR/NNU=;
 b=ei02iFyQ4gagV8mXgBr9Dj7x8ttBWlJn/DBe51Rxk22sYcOvRl3geKAJTBe3X835XDRVzKqTN3ea/AJ8blo5bKi+17QrIqPZKldiSrbsZytMCiG3AR1iS+hjlNf3gEzBMpbTY8WKZa6CjHLKZKyk79p7ReQSLjI3k3Iav1cpXuA=
Received: from MN2PR10MB4112.namprd10.prod.outlook.com (2603:10b6:208:11e::33)
 by DM6PR10MB4394.namprd10.prod.outlook.com (2603:10b6:5:221::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8489.18; Wed, 26 Feb
 2025 05:42:55 +0000
Received: from MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c]) by MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c%7]) with mapi id 15.20.8489.018; Wed, 26 Feb 2025
 05:42:55 +0000
Date: Wed, 26 Feb 2025 05:42:53 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jeff Xu <jeffxu@chromium.org>
Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com,
        torvalds@linux-foundation.org, vbabka@suse.cz, Liam.Howlett@oracle.com,
        adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com,
        benjamin@sipsolutions.net, linux-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org, linux-mm@kvack.org,
        jorgelo@chromium.org, sroettger@google.com, hch@lst.de,
        ojeda@kernel.org, thomas.weissschuh@linutronix.de, adobriyan@gmail.com,
        johannes@sipsolutions.net, pedro.falcato@gmail.com, hca@linux.ibm.com,
        willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com,
        linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de,
        rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com,
        f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com,
        mingo@kernel.org, ardb@kernel.org, mhocko@suse.com,
        42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com,
        enh@google.com, rientjes@google.com, groeck@chromium.org,
        mpe@ellerman.id.au, aleksandr.mikhalitsyn@canonical.com,
        mike.rapoport@gmail.com
Subject: Re: your mail
Message-ID: <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local>
References: <20250224225246.3712295-1-jeffxu@google.com>
 <e697ee1d-6075-4f24-8365-32aa4bc84d7e@lucifer.local>
 <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com>
X-ClientProxiedBy: LO2P123CA0093.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:139::8) To MN2PR10MB4112.namprd10.prod.outlook.com
 (2603:10b6:208:11e::33)
Precedence: bulk
X-Mailing-List: linux-hardening@vger.kernel.org
List-Id: <linux-hardening.vger.kernel.org>
List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN2PR10MB4112:EE_|DM6PR10MB4394:EE_
X-MS-Office365-Filtering-Correlation-Id: 114316d5-5ee0-4b51-6fae-08dd56286b30
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MXkxQzFycE5wZUR0RXM4NldNMlVxRXVWMU01ZmVIMi9yNFgyZWRlNytEMHBr?=
 =?utf-8?B?aC9HQzRtS2laY1hrL24zdW1WRU4wQ091T3dwOUxmcjFqTjVyVVQ0bkxTZ1Vk?=
 =?utf-8?B?TUF1elhJMGtWRVBPd2wvUktKc21JWHU5cHl1Zk5PbjdOenFRYUljSDBTWEl1?=
 =?utf-8?B?R3JjY1RlNDE3NVBzbnhHMWloeml0TC96ZlBKTXNRS1FkK2kxQ3JTS3crdFYr?=
 =?utf-8?B?bnJmNW5nQ1hVNlRibFFzZzhVTWhPKzdLVTI0blUzVFJkcnY2d05ONVprNnRu?=
 =?utf-8?B?clBkcEtxYzZWNVZMSnFZZ01RREk3NU5JUHNZY3VvODIrQitiNEFaWDFTVEhj?=
 =?utf-8?B?Q1kvcWJRU0JtWEVvYmJYUkE4bCtOVkRmRXZEMXFzSnc2VUErYTZONmp4dzI1?=
 =?utf-8?B?WVNWTmMzNjlSR1BiUzhzeUJ2MjhBR0JtMTYwQVZNMDRPK2hXa3hvdkZzcXI1?=
 =?utf-8?B?RWhYSDN1b2hGV1htVWZBRkpySkZYckZhZXVad3JGVnUxYlNxeklzeVhVcWVm?=
 =?utf-8?B?OCs2aGx2Ty8vU3YwdFFQTXZTRjJMMVZpQlZybHpWREpsVHVKZ0RaeWE0WUtq?=
 =?utf-8?B?eDNjdjVrRTgzTlRYNGNhbjc0d0RiSk9obWgyS3FBeHZielVseDIxOEhCVjB2?=
 =?utf-8?B?MUduWmVuRWxQVjJXbzMvUkdzbGVGY3Z4eWdtQ3RiMnJvN0tTQ1o0enRvSkVu?=
 =?utf-8?B?QkxNNHFOaTlJS29kVUJDT3BydEd0VFhTa21GWXdjKzlQRk10TElVdUZiUENT?=
 =?utf-8?B?Y09LL1ZpbWxRaitTM2xuMGRVV1I0aDB5dmg1R0tTdElXSVp2algyZ3FzTWE0?=
 =?utf-8?B?MUMweWVtN1ZmR1h6dVdFdW8yOFQ4VHJ3aGRhcVdaVTV0YytPWERiQitLRnRz?=
 =?utf-8?B?bE5lQjVXRCtKZkVWTkJTRjRiU0JrWjBtdU0zYmJSeDhrMXJLc3k0aU5RSkZS?=
 =?utf-8?B?VjlGNDZCQmdFRUFPRmwrYzlSVW1GUjZnUFE4bTZmWDBHU01malY5Um1zU1h3?=
 =?utf-8?B?Y3FBbVVHV0tuZU9kSmdCakQyemwyQitpbDFwUWphL2xjY3lmekpVNEpYMTU1?=
 =?utf-8?B?WlgwN2JQQytMQlBFb282Mzhyc0I1TEkrZCsvMDZxNHovdzdrQyt2Vkhqd1VO?=
 =?utf-8?B?WDRBaXZiVmpCZmRmZFJyUGJMWDZFNGdEV2hQNW04Ri81cElXTklUTkh2UEZM?=
 =?utf-8?B?NlUwcGM4YndES0tNZzVucXpXM3lVYThZTE13TnE1cmhMM1htdk4yUnI3UTly?=
 =?utf-8?B?aFJNTk9Mc0lRdFhENHM1TFF4eE1hdXJteUFlOUcyeTd6RzdCVTNacE9pQTVZ?=
 =?utf-8?B?MmNORU5OcjNKTFZ6QW1UTEdFdHZQdlNRVklEZ2lsWkRkQ3dVYXZMU0NMYVpI?=
 =?utf-8?B?Z0lJTWZjck8xTVFQRnpXYWdYeUt0Q2RuUUxSeXVSaHhobXpCZUhQb3ZxV0RH?=
 =?utf-8?B?bVg0WExxdThWV3plTzJqeHdmUm1zaUMzTnJLdDJUY2FZSFJ2b2pVVGhRWTNj?=
 =?utf-8?B?bWVsaXVPQmVsaGZQV2Z4aU9IZXp5ZFZycEJwelpPbWJpRzVycDFXSVFwUzFr?=
 =?utf-8?B?M2pwV2pzRFpCUGRGL0xIQkkxRjZ3QnRENGJBYWxaUDJLd0ZaY1VsTGNrS2xL?=
 =?utf-8?B?dGRLdlhZUkx4RzFLYzdXc0p6NTl0cmJwbUlUVmVETWdMKzNaWmNJUjdoSXBa?=
 =?utf-8?B?QlVRK054akJ6Zkxya2lSWkxiWDRVT2pnb0xTZEFKYXFtd1h1TzlVK0NXNVdi?=
 =?utf-8?B?UkU3QlBVek05WFlFV1JHbEtPdzNuTDE1cnJsMkIyR3hCaHAxODNKTFBSK3dL?=
 =?utf-8?B?MmdOaWlMVURxYVpnTHhLcnZORFc3TTUrY3ZvbThQM2pCblJieGpvSTEySmJF?=
 =?utf-8?Q?MkSRiIFspWPjq?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB4112.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?K2p3SzM5endZWHpOSEVLYjJrSGdFa0JNNVlSb3pLZjNHWVU4VXZ3R3BQSFhI?=
 =?utf-8?B?OU9CZkZLTzkyZGZFcG9BZFd1WkJyaGFtSXFCZnVOOHUraHozeFcrWkM5MEt0?=
 =?utf-8?B?Wk11MDdQZjRoOUtpRVhmdjFUeUhDbFZGdmNuMVo3aW1MbFdzejdCT1RZZDBP?=
 =?utf-8?B?RDhSVnovRUcvSUhPVkpBMWlaaWsxVGFoOEV3QStkblVta3ptOWkzMUpFa2xi?=
 =?utf-8?B?cHJOcklCRElSZlA2UmZtSlFQR0xReVYycC90VnlUZEkrR3JJK2phcEtIb0Fv?=
 =?utf-8?B?S3JSbTI1bDlzN2RJRVYvYWpzWGxlSGt5L09IWHBDTHU3QzczbEYzT0ZHbkNH?=
 =?utf-8?B?Z2l1cmltd2dhM2lEK293V0RwMEx6NXVnMEw1U0pTSHhFSUVUWFQydXFEY3lI?=
 =?utf-8?B?bC9vaG15eUpqRFNYWDBKT3dqbnI5eDNrRWY1OWZGTEZxZ0E4b1BZUzN0bkpm?=
 =?utf-8?B?OHZuVEZDSExoVmI3R2JWT2p5Q0RuZFNrajdLYStObG1BamhoYjAwWGEwRWg2?=
 =?utf-8?B?VWxpbGxPVjZiWkt3Z3p1TnMvK21HK0tiWFBBRXN0VmxqZkoxaUJFeFhISGdl?=
 =?utf-8?B?Uko1d1JhdFc0VDAxRnlPT05qMHRIZkFDdzdEMU9ncHFGZk5nemx1U1ZIOWF1?=
 =?utf-8?B?UExPS2Z0YlVPY1puRnR3T29xaEFQVDQzQ2FrNGYvVktuaklGVXdENlh4VVdY?=
 =?utf-8?B?MEhDdk5SREhtWU41dng4ZWNUZXhzVGU3dG14Ukw1Ymt5ZmZzWTRrcStaRFVL?=
 =?utf-8?B?RVl1OXMvWnhIcFZkNFIvV0R1ZXVOTWdHNGdtSDdWdkVkRitaT2JCb2FFRUhB?=
 =?utf-8?B?VGoxUGk4OE9CVkt0eHZZSGRHcVdxV0VEcURmeXlHSUUxcldjemlyVVBnTXNR?=
 =?utf-8?B?UE1QQytDdkFqNHc5WjYzc2p4WS9IMUo5WEFDV3pHMlF3SG8rQU9SRUxwdDBH?=
 =?utf-8?B?ZGJuSkR1RndkVUs2WmdTTkxLVzk0TnNyQzVyMGxwZm9YWk9JU0N5RWlsdXdx?=
 =?utf-8?B?aVczVXdXZlZaSjlXcTBjRnBzZ21FVWNrMWRRRlFlNXhYUWdKVTdUWUo5elFt?=
 =?utf-8?B?bnFaNGM0dHVsV2xJY2xoRGZSaGNrOTR3WjFxNGRWMFdFSlFRTmVPZFIrMVZr?=
 =?utf-8?B?a2VvckhNM2I3OGI2cDl0MEZaZUFtSmFWQ0lMZUcybkZaNnY1aG9FeEpKZUNu?=
 =?utf-8?B?T0Zrak1MelpXRVpWdHYvU2puWTNWSmROMjVrdDRWVGZsdDdKay94MG93TlNF?=
 =?utf-8?B?SGcrVXhSWkVYV3BSK3FialpNa0IrcXR4ZGplcjE5Vlp0QWFLbW1qS25URm9U?=
 =?utf-8?B?Zjg3SlNXSlh5TmNibkNpMkYyb1BXVFJyTndwVURaWWNtc21lS1RuYmFWaFpo?=
 =?utf-8?B?MUQvSGtiUkdyeVZGb2pNNVc1NEFGdWhtS2tkWVlFbmM2VEVIblJMYVg2Z3Bq?=
 =?utf-8?B?WVFVMU5RT2ZJS0tsczN4REpuZGlSalFQcXpoU2hWdFZNdlVQZXMzTjZqeldG?=
 =?utf-8?B?RldzYnhDVTFkMityZXowUFdVYUhXSjZvLzRRdW53QzRabEtpZlNwbDBaTHhS?=
 =?utf-8?B?WDc1L2tzN1V6Z1VzbjBCZlFWUnF6cStreTBsbUE2OENCbDAxM0J0SDVIdHFL?=
 =?utf-8?B?WVE2eTcrMlJMNXU4cWptdkQ0UU8zaGJvZGpBU25rRVBvNS9VTWlIaDc4Z1N3?=
 =?utf-8?B?SHd2MDgrOEl5NXd4U3pZVHRvZUV5V3FwUDRqQnQ5VFRpK1VqaW1RcTZZNmE1?=
 =?utf-8?B?NXNJYTF3bXhJM0I2a0VQb0xka0NJTlMrRUdyckNqSXNFN05BdDF0Uy82WFFr?=
 =?utf-8?B?QWloSlhSb1NtN2x6VUliaU9KNnlSMytDYXhtaEpnTDlxYnROZkdURnl6eU1a?=
 =?utf-8?B?VHJNVWVUc1VwQ3FySmxrOXJQYjRZTzFmWktrTUxEc0N3NUM1WlZSY0JRdDNa?=
 =?utf-8?B?S1VjeFg0N1hjSGdxQVdTMDZHTWg3NUkxcUhSdTZuaFlOdHhOQ3hYMFVwTGha?=
 =?utf-8?B?dmYvSDBIRHpVUGEvbzhwNHIvVHBZTDA5OG1scTBHeElNdVdCZ3hjTW9oQUxC?=
 =?utf-8?B?WWhydFhteGtPNDhYTWpaTm82enlUTEpaNGM5R3o0MXVxcVNNQi9BR0dybzZW?=
 =?utf-8?B?ZUFHNERvRmN3RWJYdGVvU2d3b2hiSUVBdWZ0UVY5TWlyelBGbmtKRndWZy9x?=
 =?utf-8?B?L3c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	 
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 114316d5-5ee0-4b51-6fae-08dd56286b30
X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4112.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2025 05:42:55.5614
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jOA5XrqiorsuDtRaWAOvTwW4Dh8n2cB19+IlAEHMLWoNgztwIOCFZN2w9fGlrDak5oviZwpSbg8n3NSqVIxAiPxc/55HGcl9aIwICx4JNsE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4394
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-02-25_08,2025-02-26_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999
 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2502100000 definitions=main-2502260043
X-Proofpoint-GUID: xLDO75tYB4aIH2Q9-D5jtxxEUJ24Ussn
X-Proofpoint-ORIG-GUID: xLDO75tYB4aIH2Q9-D5jtxxEUJ24Ussn

On Tue, Feb 25, 2025 at 04:12:40PM -0800, Jeff Xu wrote:
> On Tue, Feb 25, 2025 at 7:18âŻAM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > Jeff - looking further in this series, I asked for a couple things for this
> > series which you've not provided:
> >
> > 1. Some assurance based on code that the kernel-side code doesn't rely on
> >    VDSO/VVAR etc. mapping. I gave up waiting for this and went and checked
> >    myself, it looks fine for arm64, x86-64. But it might have been nice had
> >    you done it :) Apologies if you had and I just missed it.
> >
> Thanks for checking this.
> Do ppc in kernel code unmap/remap  vdso ?
>
> I am aware that userspace can remap/unmap special mappings, but I
> don't know if the kernel will remap/unmap a special mapping. Could you
> please point out the code ?

Again as discussed in other thread, let's leave this until as/when you try
to attack PPC. I am not 100% this is the case, I may be mistaken sure, but
gathered it _might_ be.

>
>
> > 2. Tests - could you please add some tests to assert that mremap() fails
> >    for VDSO for instance? You've edited an existing test for VDSO in x86 to
> >    skip the test should this be enabled, but this is not the same as a self
> >    test. And obviously doesn't cover arm64.
> >
> >    This should be relatively strightforward right? You already have code
> >    for finding out whether VDSO is msealed, so just use that to see if you
> >    skip, then attempt mremap(), mmap() over etc. + assert it fails.
> >
> >    Ideally these tests would cover all the cases you've changed.
> >
> It is not as easy.
>
> The config is disabled by default. And I don't know a way to detect
> KCONFIG  from selftest itself. Without this, I can't reasonably
> determine the test result.

Please in future let's try to get this kind of response at the point of the
request being made :) makes life much easier.

So I think it is easy actually. As I say here (perhaps you missed it?) you
literally already have code you added to the x86 test to prevent test
failure.

So you essentially look for [vdso] or whatever, then you look up to see if
it is sealed, ensure an mremap() fails.

Of course this doesn't check to see if it _should_ be enabled or not. I'm
being nice by not _insisting_ we export a way for you to determine whether
this config option is enabled or not for the sake of a test (since I don't
want to hold up this series). But that'd be nice! Maybe in a
/sys/kernel/security endpoint...

...but I think we can potentially add this later on so we don't hold things
up here/add yet more to the series. I suspect you and Kees alike would
prioritise getting _this series_ in at this point :)

You could, if you wanted to, check to see if /proc/config.gz exists and
zgrep it (only there if CONFIG_IKCONFIG_PROC is set) and assert based on
that, but you know kinda hacky.

But anyway, FWIW I think it'd be useful to assert that mremap() or munmap()
fails here for system mappings for the sake of it. I guess this is, in
effect, only checking mseal-ing works right? But it at least asserts the
existence of the thing, and that it behaves.

Later on, when you add some way of observing that it's enabled or not, you
can extend the test to check this.

Thanks!

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50096276D08
	for <linux-hardening@vger.kernel.org>; Fri, 28 Feb 2025 00:55:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.180
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1740704121; cv=none; b=IMeVhf35r5Vu3FUTW7Ijkf2WOHB+hK5o/t0ypHo0Bc//OSlM4wHxO50OZ8OI6AYpXzqWz274sIqXHEogpHbMuE2S6pM7kWG9mIHIRW0Oaa2K79vcEFMYJM5TNOMEXHspGpJXNp5SOYeMPjm/B5oqwN1OdcOxNdlnvMmY+HcUaDw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1740704121; c=relaxed/simple;
	bh=i5NT1VeGTEbGaE4F5Qvom40arOq2xVQJIa1NJGDG98M=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=p25eFrW4ijrkJ+ba7Utl6uGmTrOpcRR4rQcfw2ds8t3RLBMzPxkqqJi9asGVurnxwYiZd8XnbcLXQFkCWHNNj6Kc6VrUuMJDt3Uhe/VVYUH7J5YY+itWSn5fhPXDzeXemzU7RS8y4ilnJe9zt7wr2QGpvNheaXu8V/Ah89UYwr0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=cGPQw5KE; arc=none smtp.client-ip=209.85.167.180
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="cGPQw5KE"
Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-3f411a225a2so24502b6e.1
        for <linux-hardening@vger.kernel.org>; Thu, 27 Feb 2025 16:55:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=chromium.org; s=google; t=1740704119; x=1741308919; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4XdIbSK97U2bcx4CS9xaVietnaFUPHThbia6b1sB6bY=;
        b=cGPQw5KEe052xcijI7mn07ZnRQ7V7SNeSD6XSljwV5NpJfieK74s2v4KIzWXR8kWcv
         pt/NU8VYTooK/KrMhasxeRnzzS3RLQtfHb6y3jd/PrxODcNmQnJNXAD5l0h8xzVBowCV
         i3184J02H4kWRXGMmFLLxzmRcHmSqkhIPklZ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740704119; x=1741308919;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4XdIbSK97U2bcx4CS9xaVietnaFUPHThbia6b1sB6bY=;
        b=Ad37J5yrYYJs/YseD3jjdwMwAraEj1ma/aHeB9uptYu0zu82TpvsA6nviwAQJVP3wO
         KkyX3tzox0OPiOA9Fl3SxAlnFU3uVkeuskrdATMAA9wYNtj0x0P6INgBY0B++IoYVx38
         j4oWHANZhz2C1anOtEz0ALXs4jbRNpvFNQPvhJbwL/l9E5XC4H2HuzaU0PcSn2xG8Gsw
         O8QeIYvqM7seJ5EH9I52fteRH9raQmEQi1NH5Lky/kkEBrkbgzrZtD5mzo6bvwjbvv0k
         1gB+lhCpIRHcMWsi8Qu3KfDAmEECRvYDCZ1rRYL6ZsMAdYOmRwXZ7jwtS3B8Iqj5Z42j
         tSvw==
X-Forwarded-Encrypted: i=1; AJvYcCVjOdGVzqqKFeop0ywTAGEjbfEX97pZ/ptA1GSBq3u531LFWsdu9HeDgVmyg2zG4SxIEBfgiA5ycj6TMNEF4P8=@vger.kernel.org
X-Gm-Message-State: AOJu0Yx1Nb2EYZvdS24vvz75q+1+L2M5O4dr9tkSBqnO1U42kJyw07mp
	5FFk/hhnSQ09cFP5IzbkNZs8ZorWiVayYJBSaaepz7zD3hzKDyojb9eQyW4huzs3zDRVbZFGr57
	xVklhV6AFteLe61BK6nwQjJ2r3GL0GJQGN6rc
X-Gm-Gg: ASbGncu+q8qp86HQ0sfwMsEoMCciDlLnxmc3j+GmJVwl4PAO7lygq1J8K177esyz5VV
	oqWcqLTP7ZKZYY8yLF3YdJU5kCPTGnevEUkivF7BC788R9/RN3/DVHC630hBK5pbk+0hhto406c
	DI2viSAd2oNR4Lw3r3Y1Oc0KoxFdDusMsari4vdrYB
X-Google-Smtp-Source: AGHT+IEE2Zd0YzlD1eKMXngbEqBUP4PcSWI2iH/mCQwG/4t9rw5I6pMzSFtNyw80iCn/K5sXKW6A8N4md+Tsh7pLQmA=
X-Received: by 2002:a05:6808:bcb:b0:3f4:ad6:519c with SMTP id
 5614622812f47-3f5584f047bmr344626b6e.2.1740704119270; Thu, 27 Feb 2025
 16:55:19 -0800 (PST)
Precedence: bulk
X-Mailing-List: linux-hardening@vger.kernel.org
List-Id: <linux-hardening.vger.kernel.org>
List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20250224225246.3712295-1-jeffxu@google.com> <e697ee1d-6075-4f24-8365-32aa4bc84d7e@lucifer.local>
 <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com> <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local>
In-Reply-To: <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local>
From: Jeff Xu <jeffxu@chromium.org>
Date: Thu, 27 Feb 2025 16:55:06 -0800
X-Gm-Features: AQ5f1JrkAFHfI5uVGX9oxsAvwNBUue9qkGMdRly8ZF6iNxbuavzAsApzVHFK-rU
Message-ID: <CABi2SkV2_-LYGjROm3cs8nHrzBiw7pjpe0i7QGNPsPKHSeajog@mail.gmail.com>
Subject: Re: your mail
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Kees Cook <keescook@chromium.org>, 
	Jann Horn <jannh@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, 
	Vlastimil Babka <vbabka@suse.cz>, "Liam R. Howlett" <Liam.Howlett@oracle.com>, 
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>, Oleg Nesterov <oleg@redhat.com>, 
	Andrei Vagin <avagin@gmail.com>, Benjamin Berg <benjamin@sipsolutions.net>, 
	LKML <linux-kernel@vger.kernel.org>, 
	"linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>, linux-mm@kvack.org, 
	Jorge Lucangeli Obes <jorgelo@chromium.org>, =?UTF-8?Q?Stephen_R=C3=B6ttger?= <sroettger@google.com>, 
	"hch@lst.de" <hch@lst.de>, "ojeda@kernel.org" <ojeda@kernel.org>, 
	=?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>, 
	"adobriyan@gmail.com" <adobriyan@gmail.com>, 
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>, Pedro Falcato <pedro.falcato@gmail.com>, 
	"hca@linux.ibm.com" <hca@linux.ibm.com>, Matthew Wilcox <willy@infradead.org>, 
	"anna-maria@linutronix.de" <anna-maria@linutronix.de>, "mark.rutland@arm.com" <mark.rutland@arm.com>, 
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>, "Jason@zx2c4.com" <Jason@zx2c4.com>, Helge Deller <deller@gmx.de>, 
	Randy Dunlap <rdunlap@infradead.org>, "davem@davemloft.net" <davem@davemloft.net>, 
	Peter Xu <peterx@redhat.com>, "f.fainelli@gmail.com" <f.fainelli@gmail.com>, 
	"gerg@kernel.org" <gerg@kernel.org>, 
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@kernel.org>, 
	"ardb@kernel.org" <ardb@kernel.org>, "mhocko@suse.com" <mhocko@suse.com>, 
	"42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "peterz@infradead.org" <peterz@infradead.org>, 
	"ardb@google.com" <ardb@google.com>, Elliott Hughes <enh@google.com>, 
	"rientjes@google.com" <rientjes@google.com>, Guenter Roeck <groeck@chromium.org>, 
	Michael Ellerman <mpe@ellerman.id.au>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>, 
	Mike Rapoport <mike.rapoport@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Lorenzo,

On Tue, Feb 25, 2025, 9:43=E2=80=AFPM Lorenzo Stoakes
>
> > > 2. Tests - could you please add some tests to assert that mremap() fa=
ils
> > >    for VDSO for instance? You've edited an existing test for VDSO in =
x86 to
> > >    skip the test should this be enabled, but this is not the same as =
a self
> > >    test. And obviously doesn't cover arm64.
> > >
> > >    This should be relatively strightforward right? You already have c=
ode
> > >    for finding out whether VDSO is msealed, so just use that to see i=
f you
> > >    skip, then attempt mremap(), mmap() over etc. + assert it fails.
> > >
> > >    Ideally these tests would cover all the cases you've changed.
> > >
> > It is not as easy.
> >
> > The config is disabled by default. And I don't know a way to detect
> > KCONFIG  from selftest itself. Without this, I can't reasonably
> > determine the test result.
>
> Please in future let's try to get this kind of response at the point of t=
he
> request being made :) makes life much easier.
>
There might be miscommunication ?
This version is the first time you ask about adding a self test.

IIRC, you had comments about providing the details of what tests I did, in =
V4.
As a follow-up, I added a test-info section in the cover letter of V5

Though I have thought about adding a selftest since the beginning,
there are two problems:
1> This config is by default disabled,
2> No good pattern to check KCONFIG from selftest.

>
> So I think it is easy actually. As I say here (perhaps you missed it?) yo=
u
> literally already have code you added to the x86 test to prevent test
> failure.
>
> So you essentially look for [vdso] or whatever, then you look up to see i=
f
> it is sealed, ensure an mremap() fails.
>
This suggestion doesn't test the core change of this series, which is
to enable mseal for vdso.

When the vdso is marked with "sl", mremap() will fail, that's part of
the mseal() business logic and belongs in mseal_test. The mseal_test
already covers the mseal, and this series doesn't change mseal.

As for the "sl", as I responded in the "refactor mseal_test" [1] , it
will be part of the verifying step:

[1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17mGy-=
XutSTAwg@mail.gmail.com/

> Of course this doesn't check to see if it _should_ be enabled or not. I'm
> being nice by not _insisting_ we export a way for you to determine whethe=
r
> this config option is enabled or not for the sake of a test (since I don'=
t
> want to hold up this series).
>
> But that'd be nice! Maybe in a
> /sys/kernel/security endpoint...
>
>
> ...but I think we can potentially add this later on so we don't hold thin=
gs
> up here/add yet more to the series. I suspect you and Kees alike would
> prioritise getting _this series_ in at this point :)
>
> You could, if you wanted to, check to see if /proc/config.gz exists and
> zgrep it (only there if CONFIG_IKCONFIG_PROC is set) and assert based on
> that, but you know kinda hacky.

Ya, it is hacky. None of the existing selftest uses this pattern, and
I'm not sure /proc/config.gz is enabled in the default kernel config.

One option is to have ChromeOS or Android to maintain an out-of-tree
test, since the configuration will be enabled there.

Option two is to create a new path:
tools/testing/selftests/sealsysmap. Then, add
CONFIG_SEAL_SYSTEM_MAPPING=3Dy to the config file and add a selftest to
this path. This seems to be the preferred way by selftest, but we need
a new dir for that.

Option three is to add a self-test when we have a process-level opt-in
solution. This would allow the test to deterministically know whether
the vdso should be sealed or not.

>
> But anyway, FWIW I think it'd be useful to assert that mremap() or munmap=
()
> fails here for system mappings for the sake of it. I guess this is, in
> effect, only checking mseal-ing works right? But it at least asserts the
> existence of the thing, and that it behaves.
>
> Later on, when you add some way of observing that it's enabled or not, yo=
u
> can extend the test to check this.

I think it is best that we don't add a test that doesn't actually
check the code change. Do you think one of the above three options
works ? maybe the second option (with a new path) ?

In any case, I think the risk is low, and the code changes are quite
simple, and fully tested.

Thanks.
-Jeff.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98740256C8A;
	Fri, 28 Feb 2025 09:36:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1740735381; cv=fail; b=ewaV/KkwAHNcSOCixVw90RSAEzDtyUNNThBbPHRs/cun6ZyHNNhtE/14PyC04n92dJxdWu6Fe+A49jWuWNEbo4la7/PYv7ltRuFtV3XjzNj6iZ4QTYEbkyU5tv4BKq3D1yJjvR9di/3JJIO0xfpqhJZn0F67+g9vQNGUyNWFXuU=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1740735381; c=relaxed/simple;
	bh=QbZpt3QpC7/3O7nMc2b4XuHj9aZ2yNCjUVVLOynjc1E=;
	h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
	 Content-Disposition:In-Reply-To:MIME-Version; b=F2VXSZyeXw9UW6wpXBRc3v0AsSM7hSb67OgRHITH5dVa7C/dBe5S6/b83G7TRzYFTe2aziBobzgP8lcToejhO7Kan/V5Myw8oWaU2YtbRXODrm4wBrqG8iI9pwyPo7KDMIw/Ickk7PvZ6RjLmT+en3BEQitVzFxtXukz14eyFL0=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=QzCcslVl; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=AIWcS0Aa; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="QzCcslVl";
	dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="AIWcS0Aa"
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
	by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 51S9Be0N027517;
	Fri, 28 Feb 2025 09:35:23 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=ruydLUBuUs+bQ1QDoJW07OEhUiT/g4Vc31oc84FW52U=; b=
	QzCcslVlFMeRrbMXmju/abP+hdK7BzYp9oxUWXv/SbeuGuxb5pQcfdf7VnZzsGPF
	WMWPKpYtkhxe49ipwyWRaiQV3oCrEKolc+2RSWDjexy1moLPZtHxtw6LC5ZVyTv5
	Ep8/7rhqr9kIzkcgvEk9Rh4hyK+IwRAW8OmMQs8z6Iwp9k1+cQd8htKD/Qb2S+L/
	z5Dr6kpF5lmaeUFLmH6q4J9inREsAgvQ2NZgEhtRnAanOGWu+iWxmOmA0t51Ouns
	IqnsUOb0rWAXFnZtIh4hcri1OQgjqCIzNkDwxJH7v3kcbCD++czkH18Sz6LqtlCW
	p6y89civSPT2Q3krMVltTg==
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
	by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 451pse563k-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Fri, 28 Feb 2025 09:35:22 +0000 (GMT)
Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
	by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 51S91M04025293;
	Fri, 28 Feb 2025 09:35:21 GMT
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2170.outbound.protection.outlook.com [104.47.58.170])
	by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 44y51m0npg-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Fri, 28 Feb 2025 09:35:21 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eEg+oknx7hsStCB/kj1fIIH2IaBgpGFxRdbfj15FavkK6tyzK+xtFgk2CZJeL4wtB5BXuz88kVXiILFqWA9GW8ZQ7O614Az00UoFwpa8fsmhkF5Z0X0hUlEW2fATPuHPTBN8SSxUSfoAdghjjXtRomEl1D/Pw9yqcX6294LyTfYIA5PTD/USJMP6TfRQcIhTP8jQ4yUig8hmiD3oy5u8NLc1Rw5jVwvbpF6L+zUAhXsj11HAZWPUGsff9cCiAu9nC0LuPBoGtFF9kPPaL3aexs6Qj4eoOUsjvpup8lt0rgGPN74PLocvqhdwIA4NeFmcS2I73kCfOuPx8FLUFt5M/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ruydLUBuUs+bQ1QDoJW07OEhUiT/g4Vc31oc84FW52U=;
 b=Urk99QJDsQclo1/3gT746nu04HZj1ra1DSKwVZf7FTRD/I470WkEXsu/gHLPAar5YSDD/IFGNtoDvxdwv/rOrg2GsZUI2hzhM2C45np9IobzVXHKxVbHpzyklounbKqvjJyMERNzbAQ24HeIe50Rzv3sepRR9TDEOA+h2BPYtsKuZzk08lrX0t7yrtPir43Y+SOl0FxtCTM8gGEnBSmLPn88Hw0hj9bejiXVqWYkQU8K4igo+qSTL3FVQpfcaoGW8vaomvvfUXYqGlSa24hpf0eMUt5sltD/6ytCtnIvWW142+lN5BfdJvurF2XxiSQY6N4F1f+C4eMncTl4VDMSSg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ruydLUBuUs+bQ1QDoJW07OEhUiT/g4Vc31oc84FW52U=;
 b=AIWcS0AawUTkEH9Tw57uo7JTxD0zjb6I3/BGaZsPlTcMLqV2SIfChSqfK0bgPlk2vionr0Qtt0tq6FIORCcPl1E81DiY4/d09rTXO3ors3dlQFvfXWfei51JfnJvIqoz2mDBJoVC47jufDgCKtT64OhoHte2zy0a+wYMvj0+Doc=
Received: from MN2PR10MB4112.namprd10.prod.outlook.com (2603:10b6:208:11e::33)
 by PH8PR10MB6573.namprd10.prod.outlook.com (2603:10b6:510:227::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8466.19; Fri, 28 Feb
 2025 09:35:18 +0000
Received: from MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c]) by MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c%7]) with mapi id 15.20.8489.018; Fri, 28 Feb 2025
 09:35:18 +0000
Date: Fri, 28 Feb 2025 09:35:16 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jeff Xu <jeffxu@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Liam R. Howlett" <Liam.Howlett@oracle.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
        Oleg Nesterov <oleg@redhat.com>, Andrei Vagin <avagin@gmail.com>,
        Benjamin Berg <benjamin@sipsolutions.net>,
        LKML <linux-kernel@vger.kernel.org>,
        "linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>,
        linux-mm@kvack.org, Jorge Lucangeli Obes <jorgelo@chromium.org>,
        Stephen =?utf-8?Q?R=C3=B6ttger?= <sroettger@google.com>,
        "hch@lst.de" <hch@lst.de>, "ojeda@kernel.org" <ojeda@kernel.org>,
        Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>,
        "adobriyan@gmail.com" <adobriyan@gmail.com>,
        "johannes@sipsolutions.net" <johannes@sipsolutions.net>,
        Pedro Falcato <pedro.falcato@gmail.com>,
        "hca@linux.ibm.com" <hca@linux.ibm.com>,
        Matthew Wilcox <willy@infradead.org>,
        "anna-maria@linutronix.de" <anna-maria@linutronix.de>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "Jason@zx2c4.com" <Jason@zx2c4.com>, Helge Deller <deller@gmx.de>,
        Randy Dunlap <rdunlap@infradead.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        Peter Xu <peterx@redhat.com>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "gerg@kernel.org" <gerg@kernel.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>, "ardb@kernel.org" <ardb@kernel.org>,
        "mhocko@suse.com" <mhocko@suse.com>,
        "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "ardb@google.com" <ardb@google.com>, Elliott Hughes <enh@google.com>,
        "rientjes@google.com" <rientjes@google.com>,
        Guenter Roeck <groeck@chromium.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
        Mike Rapoport <mike.rapoport@gmail.com>
Subject: Re: your mail
Message-ID: <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local>
References: <20250224225246.3712295-1-jeffxu@google.com>
 <e697ee1d-6075-4f24-8365-32aa4bc84d7e@lucifer.local>
 <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com>
 <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local>
 <CABi2SkV2_-LYGjROm3cs8nHrzBiw7pjpe0i7QGNPsPKHSeajog@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABi2SkV2_-LYGjROm3cs8nHrzBiw7pjpe0i7QGNPsPKHSeajog@mail.gmail.com>
X-ClientProxiedBy: LO4P123CA0306.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:196::23) To MN2PR10MB4112.namprd10.prod.outlook.com
 (2603:10b6:208:11e::33)
Precedence: bulk
X-Mailing-List: linux-hardening@vger.kernel.org
List-Id: <linux-hardening.vger.kernel.org>
List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN2PR10MB4112:EE_|PH8PR10MB6573:EE_
X-MS-Office365-Filtering-Correlation-Id: 1ab13c75-a43f-430f-882d-08dd57db3675
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VzB5WjBNVWdJc2ZublV0TWhmcUxKb2x1QXd6Ym1kK2w4Z1k5RkY1NWRjRDNH?=
 =?utf-8?B?SVV6TWg1NlZaWmlNQUlXYjZ6N2FhbVYzSVNxTFpqcmxxVzJ1WVVlbzV3ZVlR?=
 =?utf-8?B?blVYUlI0aHlDNDRvS1cvdWltRDFwclk4N1FCTHJzZWhkQTFBTFBnYVdaY28z?=
 =?utf-8?B?Q21SRHBROFpHU0NyRXRxT3NxRG5aSzlUVUxXOElCRmFsSWxxUTk0Q2NHQ285?=
 =?utf-8?B?YmN1dGNld25DaTFtaDNxaXhqZDJyZmZqaVNoWTBxQXdQcGNBOWlucnU2dWJY?=
 =?utf-8?B?WHZmbVY0ZVZlSnlwS3pXUkhWOTdWUHFPdVcxUHFaRjg0c0dPcll3c3F1WnFh?=
 =?utf-8?B?b25lR3g0ZGpYUUxDQkhML09NUXduSUZ3dlFyWGRWNVRoUHRnWW15d1ZpQjA5?=
 =?utf-8?B?d2tpZXo3WXlsWjFjalJQSGV5ckpMY1NQYk53MVV1K0pkM1ljZXFieFl0YnEy?=
 =?utf-8?B?WFBwRHdRY3FPVHI5VElRK09NLzExNXBZd0RWTDRYWjJUQXhpbTV5L0JSblVB?=
 =?utf-8?B?R0ZKbW1WRHZGcEFvOEEvdWFlM3N1VlRKUUlpV2hTbzhhenY5aHVVdGlpNExl?=
 =?utf-8?B?MVFiK0lTRDFLbitzaE1KNVRvd3dkTS94M0VhV3czb0lkRC82T0hLVDVETm8y?=
 =?utf-8?B?R0o4RDcyZkM0dTRLSmtMU0RKNlZNRTQ2REtBYTliTjFUNnV3UVFnUys3dFVa?=
 =?utf-8?B?YkM4aTJ6NWtJa2hXL3NBRVduRmdzK3JPUFg0a3VJWVZHMzZSQUs1Q3FjRnha?=
 =?utf-8?B?bVJqWThkZk9KaXRtdHlwOVk1ZXhHWGE1c2FkQXhncCtvUmVGa3BlSzdsNUQ5?=
 =?utf-8?B?VTUzbHRucWxUUnBoSHlmWmQ4SHhTQm9YSnBGaHc5cmRzaStsWkNLOFAzOXJ5?=
 =?utf-8?B?TEcxWEF0MDZEcEJSU2pQVkFVOUpSM1pPNWJsNUJ4SGw2bmVNa1dybmMxKytt?=
 =?utf-8?B?eEtYeGNubG43R05JcDJEcW1zL2ltaW54S3ZGSFRwZlhBbmNQRTRQaUNQSmsv?=
 =?utf-8?B?TDVZVVc1bW45VSs4bkg5aG42SWNjaSsvbmNpOWIrRXFKTVpHRWJCZ25XTkYr?=
 =?utf-8?B?angvcVFJRkZNR09yOEFobHR5cVY1S0w0RnVDbWp1eTNGWmhmZDI4SEErdE8z?=
 =?utf-8?B?cWtrRUFmYUptRGdGL0ZSSld0RnBPTkN3YSt0dHI5azBmNjJ5dUJqSnFJeEM0?=
 =?utf-8?B?UzFQRzZaYVROZFk4ZDNkTWVUdEJLN0pWclhDM3IrakRkbUJkc1U3L2lHZnRo?=
 =?utf-8?B?ZXdXTng0QXNnSldpczlMTTZwWnhjU3FyaEIvRHpub2FEMWFOSStmNVoyeUhK?=
 =?utf-8?B?bGFjSEpUaFNaNzZyMnRDbU93ZEtKcndVQ1ZqNklPekdPa2dBb3krdWR3NUJv?=
 =?utf-8?B?NG1hZlJjRmRldDJWQnlkTkRMTm5ZdGZ6YTBHc2RIcHVOSU5uQUF1OSswSGZE?=
 =?utf-8?B?VEdPN05tN21OeDBNbHVaYmZGTUpMV0llWldRbCtSbVc1dHd0cmhCaVMwOXF4?=
 =?utf-8?B?WHhMQUprdTU4K2tqZzJnWVh0UnZRNVBLTVlYUUZ4YjNUNDJzMTNjckIxYXpr?=
 =?utf-8?B?ZXhzQVYya0grTVljUVBCUmN2Um9Mdkw0TVNCdHJ4RjlkaWVackhkOUc1MVAx?=
 =?utf-8?B?c3lOTTZyWTZPSTlBcElGbFdYMHR6UmVnZFZhQkFMS2RJbXp4a0NVRC9CMTNm?=
 =?utf-8?B?Rk1jTG1IRy81bHdxcERrRDF2K3FSckdIRU9Dak9kSjRTZlZ2MFgrTnByTGtD?=
 =?utf-8?B?b3ZFdFoyY1M5dTVOK2VHODQ4dW9JdkpBNDNsTlFsRGdvWVh3dXlkK0lZQWpm?=
 =?utf-8?B?YllJQXVyd0MzclI2RU8rcW56S3ZBSjRNbDhWUkNIVzU0UmYwM2VQRlR4RFlE?=
 =?utf-8?Q?nWMtIe/FjvmT+?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB4112.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UEU5cjBBTmRqMVJuNGc3aWpKS1JhVmRLOGtuWDRlb1QvQW80SllFT3BzME1U?=
 =?utf-8?B?QzVhOGI4eTlQRDl4RS9tUm51K3F0aDlWSUdsT2RHbWJJSXVCY0lDVjE3d2ZY?=
 =?utf-8?B?dmtvRDJ4cSszbFVucEVSQ2F1SzVYcVZmK0YvOWJ1bzFta2xZdzhDNXNSTm15?=
 =?utf-8?B?ZE5xait5SWF3NnVaSGdQdXJURUtic2VKblFEWjlKMW5VTkNYK2M5a1FHYmlN?=
 =?utf-8?B?VUFtbWFxQlo1Mk1vRHkrRXVqWmxTY3dUNjRRNFlnYVl4NEpmU042QlkzclBK?=
 =?utf-8?B?V3gxYUdBcHRmUmc3ZGh4a3B4dGFVeE9RTTRySWd0SzA4dkoxbzdKVUVMRWRY?=
 =?utf-8?B?UVc4MktHem9oMnN0SGpUcmwxZUp0eVRYR0VCL3dNUzNiTFcvMW9PTUNDUWh5?=
 =?utf-8?B?cnNUL2ZpMHRpeWt0NnAwWElqTll1QzZqMG4wR2x6SnZ6dnVXVHFKMjFKRzFB?=
 =?utf-8?B?QzR1YWx1Q3oxbFJOZk13eFd4dmE5ZXdoM29NTEdNS1NzT1kvNWZEdjYrYkN1?=
 =?utf-8?B?ZS9CSE1JTWNOb3ZwZ0ZhVUFYMUN1UWRDMXBJU1VMQUh1dmNtbDhTVy9LZ3Bq?=
 =?utf-8?B?ZkoybE9oSXBnZ1VvZVBISmVzODNtR0Y4ejlLaVdSUWovUzM4d0lBUjltSExX?=
 =?utf-8?B?NTgyOEpxdDVQV2N3L1ZjUDhFZFNBYkRwTUVrRzRLQW9kL0ZRWWd0bG1lc2pC?=
 =?utf-8?B?VExncHpBZURtQnVPNjJ0T0FMdjBvc1BJalhmYmR1aFhudStJb0VzdTY5b21D?=
 =?utf-8?B?M0VETGtYZHY4emZySnJaYmJubzZZSFlmZTQwL3dwS1cySlAvL1pGbDdUczFz?=
 =?utf-8?B?NS81V1dMY1pCeWVTL09XNVZuZU44elRIU2dqVnZpTTI0SlY1U1JvSXFYRUZx?=
 =?utf-8?B?ZUlJMWFlOTlyV0gxZFZ6MjhhL3pXNmczcVl3TG1aR2hlak4wakFYL2RUMTFs?=
 =?utf-8?B?Z1RZZjZ5VGI2YXZmNlZlQzZBRmNSMHVBWFhJTTB6UmZVcjdCdXgvSjVaamd5?=
 =?utf-8?B?MmlQejhZc2tBZmZIN1o3NWtkejF6d093dHlheTZLVk1HTEJETHRHcVpTeEJH?=
 =?utf-8?B?N1I2Y0tYaFZENVJhcmZhT3JoU2ZRU3RaNE93eTlMR0Y3dmZSNHpPbDNGTHNU?=
 =?utf-8?B?UE5zL2RNSGR1K2EwdjZmQVp0MDVTdzBmNGxNWTdQNDZ5NVEyTzZkN1cvdllj?=
 =?utf-8?B?Y092ZmowRVpuZXcrMVBRSVFKbFlIcVVwZUJmWFZpUU5GaGxvSUwwQnZGVFdU?=
 =?utf-8?B?S2ZuYlVqSm5pSXI0Z0VBcHA3bzluN2JWeDZzaVVVTjNHeGl4Y0VTVm9BVE1H?=
 =?utf-8?B?clRwSm5GbEs4T2V2VElKd21NSy9ROThLNkdTSTZSMWtsUkNnMHgwRHRKUk90?=
 =?utf-8?B?WnBFY3cyRWFaa2Q0eTZoNUc0SnZiZllLVm1neG1PS21OQnlYRUlHc0MvMXEw?=
 =?utf-8?B?bkRZT0o0MXF5RUVONzlMU21NZ2EzcHY3RXBrU3BlRWc3cko5bXdGL1UyRWtm?=
 =?utf-8?B?aDh3eHZOMlBxQTl0QWJTY1o1c0ZvYTE1RnZoVXFla3d4NG9qU2hBNmFtaGpp?=
 =?utf-8?B?bVpiV1Q0Q2d5Z0xSSGtnczRYa0dabmxJVzlBOGxRSHJlbENNWllDb0w4UlNI?=
 =?utf-8?B?d3dwcE5IaVRRaVBpREUwV0FBUkFzZFJyRjdUN3E2U1F3cEhrTzBkVzViU01o?=
 =?utf-8?B?eEY0c0xpcTFYV05GcWhFbG9NTW8ySEowQmhoR0tzcGcvQmZZaDJBcGN5UTRm?=
 =?utf-8?B?NVY2UXZzTHRQTmc1d0xQWjEwTEhrcWlVSnFhQzZhaE8zbEIrblhNY2NaR2I4?=
 =?utf-8?B?TUxLUUtwSVh3bng1OUZSOXNyeC9JKzBvaHZIUGxLQWc0a1ZadHRaV3JwRzAv?=
 =?utf-8?B?RlRJRFFxSUNpd2lPZmJyVE5SYytoeXdIM0ViZmNRUnp3RzRrY3VxUE9oYVlG?=
 =?utf-8?B?YW5xWFlycWlUTVpDTitFY3I3QTA4eXJIR2tlaHFrK2dLQk1vWjJrUDNLcHNL?=
 =?utf-8?B?d0VOZHRIUWpSSVZ3TXF4eEtoRzdOZnhnNFBFZjNyWlNzU29NeW5vMWF3SWE0?=
 =?utf-8?B?YStsR0hac1ZrMFFGS2x2TTBNR2FLL2JMeEhQOTBINDQ5YVF4WEd6L29lbnpD?=
 =?utf-8?B?ME9Ockt6RUxRcDF3V2lBS3pudEVuMTZhQjFaRVlKUk14YnNiWnpIejl2MURL?=
 =?utf-8?B?Nnc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	 
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ab13c75-a43f-430f-882d-08dd57db3675
X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4112.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2025 09:35:18.1094
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WS9gHyE8er8M4NDRbltXdnGdBWPubvMroEZwNPneSy9mgYXj7rKTrmCzbew6rjVyyQ48AOffU2ulzXj2D52mlzo+5yTQ7Mh+ULraPjPwF4w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR10MB6573
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-02-28_02,2025-02-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999
 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2502100000
 definitions=main-2502280068
X-Proofpoint-GUID: fzSh9Obavh70QMkzNd8n4-G6U0m5nRhX
X-Proofpoint-ORIG-GUID: fzSh9Obavh70QMkzNd8n4-G6U0m5nRhX

On Thu, Feb 27, 2025 at 04:55:06PM -0800, Jeff Xu wrote:
> Hi Lorenzo,
>
> On Tue, Feb 25, 2025, 9:43âŻPM Lorenzo Stoakes
> >
> > > > 2. Tests - could you please add some tests to assert that mremap() fails
> > > >    for VDSO for instance? You've edited an existing test for VDSO in x86 to
> > > >    skip the test should this be enabled, but this is not the same as a self
> > > >    test. And obviously doesn't cover arm64.
> > > >
> > > >    This should be relatively strightforward right? You already have code
> > > >    for finding out whether VDSO is msealed, so just use that to see if you
> > > >    skip, then attempt mremap(), mmap() over etc. + assert it fails.
> > > >
> > > >    Ideally these tests would cover all the cases you've changed.
> > > >
> > > It is not as easy.
> > >
> > > The config is disabled by default. And I don't know a way to detect
> > > KCONFIG  from selftest itself. Without this, I can't reasonably
> > > determine the test result.
> >
> > Please in future let's try to get this kind of response at the point of the
> > request being made :) makes life much easier.
> >
> There might be miscommunication ?
> This version is the first time you ask about adding a self test.

Yeah I thought I'd been clear but this might _very well_ have been me not
having been, so apologies if so.

I mean 'make sure it's tested' is an overloaded term right? So fact you've
tested on android, chromeos, etc. implies 'tested', but also self
tests/kunit/whatever.

>
> IIRC, you had comments about providing the details of what tests I did, in V4.
> As a follow-up, I added a test-info section in the cover letter of V5

Thanks. Appreciate that! And this really does point towards a
miscommunication on my part, will try to be super explicit in future.

>
> Though I have thought about adding a selftest since the beginning,
> there are two problems:
> 1> This config is by default disabled,
> 2> No good pattern to check KCONFIG from selftest.

Yeah agreed, it's a TOTAL pain.

I wish we had a better way of doing this. Maybe a self-volunteering
exercise (*goes to write on writeboard :P*)

>
> >
> > So I think it is easy actually. As I say here (perhaps you missed it?) you
> > literally already have code you added to the x86 test to prevent test
> > failure.
> >
> > So you essentially look for [vdso] or whatever, then you look up to see if
> > it is sealed, ensure an mremap() fails.
> >
> This suggestion doesn't test the core change of this series, which is
> to enable mseal for vdso.

Right, and thinking about it, what does this test? Just that mseal works
right?

It's sort of implicit that, if a VMA is sealed, the seal should work (or
rather, tested in mseal tests themselves, rather than mseal system
settings).

>
> When the vdso is marked with "sl", mremap() will fail, that's part of
> the mseal() business logic and belongs in mseal_test. The mseal_test
> already covers the mseal, and this series doesn't change mseal.
>
> As for the "sl", as I responded in the "refactor mseal_test" [1] , it
> will be part of the verifying step:
>
> [1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17mGy-XutSTAwg@mail.gmail.com/

OK cool thanks. I will look at this when I can, I'm just snowed under
pre-LSF and have been sick so backlog, backlog as discussed off-list. But
it's not been forgotten (whiteboard etc. etc.)

>
> > Of course this doesn't check to see if it _should_ be enabled or not. I'm
> > being nice by not _insisting_ we export a way for you to determine whether
> > this config option is enabled or not for the sake of a test (since I don't
> > want to hold up this series).
> >
> > But that'd be nice! Maybe in a
> > /sys/kernel/security endpoint...
> >
> >
> > ...but I think we can potentially add this later on so we don't hold things
> > up here/add yet more to the series. I suspect you and Kees alike would
> > prioritise getting _this series_ in at this point :)
> >
> > You could, if you wanted to, check to see if /proc/config.gz exists and
> > zgrep it (only there if CONFIG_IKCONFIG_PROC is set) and assert based on
> > that, but you know kinda hacky.
>
> Ya, it is hacky. None of the existing selftest uses this pattern, and
> I'm not sure /proc/config.gz is enabled in the default kernel config.

Yeah and I'm not sure I even like my hacky suggestion here, I mean let's be
honest, it sucks.

>
> One option is to have ChromeOS or Android to maintain an out-of-tree
> test, since the configuration will be enabled there.

Nah haha, though of course you can do what you want. Really want something
upstream.

>
> Option two is to create a new path:
> tools/testing/selftests/sealsysmap. Then, add
> CONFIG_SEAL_SYSTEM_MAPPING=y to the config file and add a selftest to
> this path. This seems to be the preferred way by selftest, but we need
> a new dir for that.

OK I like option 2 let's do this.

But let's call it mseal_system_mappings (yes I"m being nitty again :) I
really want to try to _explicitly_ say 'mseal' because we have other forms
of sealing.

Not your fault, but we overload terms like _crazy_ in mm and need to be
cautious as not to confuse vs. e.g. memfd seals.


>
> Option three is to add a self-test when we have a process-level opt-in
> solution. This would allow the test to deterministically know whether
> the vdso should be sealed or not.

Yeah one for future.

>
> >
> > But anyway, FWIW I think it'd be useful to assert that mremap() or munmap()
> > fails here for system mappings for the sake of it. I guess this is, in
> > effect, only checking mseal-ing works right? But it at least asserts the
> > existence of the thing, and that it behaves.
> >
> > Later on, when you add some way of observing that it's enabled or not, you
> > can extend the test to check this.
>
> I think it is best that we don't add a test that doesn't actually
> check the code change. Do you think one of the above three options
> works ? maybe the second option (with a new path) ?

Yeah I actually agree on reflection. And yes agreed option 2 is great,
thanks!

>
> In any case, I think the risk is low, and the code changes are quite
> simple, and fully tested.

Yeah indeed, but I'd really like _something_ if possible. If option 2 is
relatively quick let's get that sorted out!

>
> Thanks.
> -Jeff.

Cheers, Lorenzo

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA5741F4C90
	for <linux-hardening@vger.kernel.org>; Fri, 28 Feb 2025 17:24:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.48
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1740763465; cv=none; b=gwOdZK7NHrGuOs63+Mw11Z0QdDeiOCW7B4uMYDVg/xUsYY2Bx4eqh/XuWf7YUGdaJzCgQVX5T13GMia0irDAYes7pe38MyIEV8/XVwIna9SbX1Q6T/1067RclCvQXeWDZeUdenbEYUJ3tUL+K77Ex9RDZ/raZZGVTqve7HLptW0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1740763465; c=relaxed/simple;
	bh=ANOo4RVFpT8QOOZI1F7Uzjr/rClfRnYnXuqCw+UeYBg=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=pKQ/dbGGzs6BDmfvt9QLIHan4nnan8FJnMzYpRJjpdvixyQ43tqtejYpt8MRsCPwDHo0Ju1GbtOFaCzLZqhN56dTLVqfo5jtX59MmxupIGPMSy3uGlTh47gUzrxP2+ey75+221bjcGXrCVrsmjQ+WXOM/rtdyvhTb/4CI1P2Ur0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=j00hy+Z0; arc=none smtp.client-ip=209.85.161.48
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="j00hy+Z0"
Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-5fcde6cdd8bso136124eaf.3
        for <linux-hardening@vger.kernel.org>; Fri, 28 Feb 2025 09:24:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=chromium.org; s=google; t=1740763463; x=1741368263; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WEwvlNxw2Xxs+TAyoZXFHjuOJ7HCWPZTchi8vXriEjI=;
        b=j00hy+Z0uetbOjPebqhsTHCIMW3MKA8WD6Yrh+ilWJ+z2YAfpOIRbaPZyRmhwcB4GT
         mMybHSgHDeqdMSnjhSXbbXbtkNhFSP59ed+WyFPgmVJxNd54fOysWnJ5GKiXb0nGyLHy
         kPJEkPr8KAkTTJ8kMa7G189NSZiixJSFXZ4BE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740763463; x=1741368263;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=WEwvlNxw2Xxs+TAyoZXFHjuOJ7HCWPZTchi8vXriEjI=;
        b=xGkYyGGcK3U+QB23U2UZqsTtePXws9y9ByPlT+FtXnYyFXaNe/Ao7duuQYdb93tZsy
         0d0sXiNEVucdCQEHuLFLp30FNfQT7B4t1O+5KckemJaKGasIPIlFpC1eBijDsfW0CBoK
         KPGmU5t0Dq4A6Ddu+9nAFrXewWrPARDDui6wVg0o9OnB6P3mNCFRPgZvnDptkQ1VUseA
         bTRTRP4g5jpRwHMlkERCmON2hkyEqLFPZnxYiG1+DJZPwknK0RlsyLkEjFlb/QaX/ivY
         ll+kdrAApR53S5VpwclbT3S/00T3wrBaI/RwptGr/MyS8So5K+I740Cr55fft+txvv5B
         2Xhg==
X-Forwarded-Encrypted: i=1; AJvYcCVJTxyC2tPJV5FkNBgf4HyyZGp6I4yfWlikUbV3NkRdNvBpv0XhqbbXXxmGLgWDTj7rArGrzPWUGj0+XikYLt8=@vger.kernel.org
X-Gm-Message-State: AOJu0YzYpsbjPcbij9RLhZzTzxsvd3DWlIRAF8lEj7b/9FmKZjWQeKhC
	1hItg9Bv7jNxpxN3ZZZtxxIBpnHBwVXEf1dRpRcWzbRwXc4aMp4xOVHVFK7uKAPlR2LhhiGEy8w
	/NLx0oSiX82e5uiLrcdwpObIGqN9wBgWF2aOZ
X-Gm-Gg: ASbGncv7ehm6IEizw3nFZ6QMpYRCDtd5PfpebT3dHAWDiGj71eKJ2Tfygsd5DffS5fL
	qPHuVjzdg7DP1IPPxFUyHKeplsHJNMtsjzC1Dv3ZJ4PMoefeoTYgXtIGGG9ANGjV1FuxsGsQhfG
	HPhKq5i5jTs3tMHLKg77OkM5QJWEqfq8fnAPjR
X-Google-Smtp-Source: AGHT+IELmIZtfBk1UK9h8+WtL5wpgAYYMKF9e2oSSIxoQJia0xhiHJ8VA3Nret0YY6RTyQeg0N3QCQfgbJs/+4ZoALk=
X-Received: by 2002:a05:6808:4490:b0:3f4:17fa:8b25 with SMTP id
 5614622812f47-3f5585f76a9mr1063932b6e.5.1740763462729; Fri, 28 Feb 2025
 09:24:22 -0800 (PST)
Precedence: bulk
X-Mailing-List: linux-hardening@vger.kernel.org
List-Id: <linux-hardening.vger.kernel.org>
List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20250224225246.3712295-1-jeffxu@google.com> <e697ee1d-6075-4f24-8365-32aa4bc84d7e@lucifer.local>
 <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com>
 <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local> <CABi2SkV2_-LYGjROm3cs8nHrzBiw7pjpe0i7QGNPsPKHSeajog@mail.gmail.com>
 <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local>
In-Reply-To: <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local>
From: Jeff Xu <jeffxu@chromium.org>
Date: Fri, 28 Feb 2025 09:24:11 -0800
X-Gm-Features: AQ5f1JrKoMI7MAoJt_s4VBjawQ2oE7qOjznd7nZIAKK-HcNxZUPVPRG1COgivdw
Message-ID: <CABi2SkX8QM7W0uCUBPFhjrC3psr1HDHLe2i-9hzh81UyKsBuQA@mail.gmail.com>
Subject: Re: your mail
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Kees Cook <keescook@chromium.org>, 
	Jann Horn <jannh@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, 
	Vlastimil Babka <vbabka@suse.cz>, "Liam R. Howlett" <Liam.Howlett@oracle.com>, 
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>, Oleg Nesterov <oleg@redhat.com>, 
	Andrei Vagin <avagin@gmail.com>, Benjamin Berg <benjamin@sipsolutions.net>, 
	LKML <linux-kernel@vger.kernel.org>, 
	"linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>, linux-mm@kvack.org, 
	Jorge Lucangeli Obes <jorgelo@chromium.org>, =?UTF-8?Q?Stephen_R=C3=B6ttger?= <sroettger@google.com>, 
	"hch@lst.de" <hch@lst.de>, "ojeda@kernel.org" <ojeda@kernel.org>, 
	=?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>, 
	"adobriyan@gmail.com" <adobriyan@gmail.com>, 
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>, Pedro Falcato <pedro.falcato@gmail.com>, 
	"hca@linux.ibm.com" <hca@linux.ibm.com>, Matthew Wilcox <willy@infradead.org>, 
	"anna-maria@linutronix.de" <anna-maria@linutronix.de>, "mark.rutland@arm.com" <mark.rutland@arm.com>, 
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>, "Jason@zx2c4.com" <Jason@zx2c4.com>, Helge Deller <deller@gmx.de>, 
	Randy Dunlap <rdunlap@infradead.org>, "davem@davemloft.net" <davem@davemloft.net>, 
	Peter Xu <peterx@redhat.com>, "f.fainelli@gmail.com" <f.fainelli@gmail.com>, 
	"gerg@kernel.org" <gerg@kernel.org>, 
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@kernel.org>, 
	"ardb@kernel.org" <ardb@kernel.org>, "mhocko@suse.com" <mhocko@suse.com>, 
	"42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "peterz@infradead.org" <peterz@infradead.org>, 
	"ardb@google.com" <ardb@google.com>, Elliott Hughes <enh@google.com>, 
	"rientjes@google.com" <rientjes@google.com>, Guenter Roeck <groeck@chromium.org>, 
	Michael Ellerman <mpe@ellerman.id.au>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>, 
	Mike Rapoport <mike.rapoport@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 28, 2025 at 1:35=E2=80=AFAM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Thu, Feb 27, 2025 at 04:55:06PM -0800, Jeff Xu wrote:
> > Hi Lorenzo,
> >
> > On Tue, Feb 25, 2025, 9:43=E2=80=AFPM Lorenzo Stoakes
> > >
> > > > > 2. Tests - could you please add some tests to assert that mremap(=
) fails
> > > > >    for VDSO for instance? You've edited an existing test for VDSO=
 in x86 to
> > > > >    skip the test should this be enabled, but this is not the same=
 as a self
> > > > >    test. And obviously doesn't cover arm64.
> > > > >
> > > > >    This should be relatively strightforward right? You already ha=
ve code
> > > > >    for finding out whether VDSO is msealed, so just use that to s=
ee if you
> > > > >    skip, then attempt mremap(), mmap() over etc. + assert it fail=
s.
> > > > >
> > > > >    Ideally these tests would cover all the cases you've changed.
> > > > >
> > > > It is not as easy.
> > > >
> > > > The config is disabled by default. And I don't know a way to detect
> > > > KCONFIG  from selftest itself. Without this, I can't reasonably
> > > > determine the test result.
> > >
> > > Please in future let's try to get this kind of response at the point =
of the
> > > request being made :) makes life much easier.
> > >
> > There might be miscommunication ?
> > This version is the first time you ask about adding a self test.
>
> Yeah I thought I'd been clear but this might _very well_ have been me not
> having been, so apologies if so.
>
> I mean 'make sure it's tested' is an overloaded term right? So fact you'v=
e
> tested on android, chromeos, etc. implies 'tested', but also self
> tests/kunit/whatever.
>
> >
> > IIRC, you had comments about providing the details of what tests I did,=
 in V4.
> > As a follow-up, I added a test-info section in the cover letter of V5
>
> Thanks. Appreciate that! And this really does point towards a
> miscommunication on my part, will try to be super explicit in future.
>
> >
> > Though I have thought about adding a selftest since the beginning,
> > there are two problems:
> > 1> This config is by default disabled,
> > 2> No good pattern to check KCONFIG from selftest.
>
> Yeah agreed, it's a TOTAL pain.
>
> I wish we had a better way of doing this. Maybe a self-volunteering
> exercise (*goes to write on writeboard :P*)
>
> >
> > >
> > > So I think it is easy actually. As I say here (perhaps you missed it?=
) you
> > > literally already have code you added to the x86 test to prevent test
> > > failure.
> > >
> > > So you essentially look for [vdso] or whatever, then you look up to s=
ee if
> > > it is sealed, ensure an mremap() fails.
> > >
> > This suggestion doesn't test the core change of this series, which is
> > to enable mseal for vdso.
>
> Right, and thinking about it, what does this test? Just that mseal works
> right?
>
> It's sort of implicit that, if a VMA is sealed, the seal should work (or
> rather, tested in mseal tests themselves, rather than mseal system
> settings).
>
> >
> > When the vdso is marked with "sl", mremap() will fail, that's part of
> > the mseal() business logic and belongs in mseal_test. The mseal_test
> > already covers the mseal, and this series doesn't change mseal.
> >
> > As for the "sl", as I responded in the "refactor mseal_test" [1] , it
> > will be part of the verifying step:
> >
> > [1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17=
mGy-XutSTAwg@mail.gmail.com/
>
> OK cool thanks. I will look at this when I can, I'm just snowed under
> pre-LSF and have been sick so backlog, backlog as discussed off-list. But
> it's not been forgotten (whiteboard etc. etc.)
>
Ya, no worry about that review, please take time to recover, I will wait.
And appreciate your time and take priority for reviewing this series.

> >
> > > Of course this doesn't check to see if it _should_ be enabled or not.=
 I'm
> > > being nice by not _insisting_ we export a way for you to determine wh=
ether
> > > this config option is enabled or not for the sake of a test (since I =
don't
> > > want to hold up this series).
> > >
> > > But that'd be nice! Maybe in a
> > > /sys/kernel/security endpoint...
> > >
> > >
> > > ...but I think we can potentially add this later on so we don't hold =
things
> > > up here/add yet more to the series. I suspect you and Kees alike woul=
d
> > > prioritise getting _this series_ in at this point :)
> > >
> > > You could, if you wanted to, check to see if /proc/config.gz exists a=
nd
> > > zgrep it (only there if CONFIG_IKCONFIG_PROC is set) and assert based=
 on
> > > that, but you know kinda hacky.
> >
> > Ya, it is hacky. None of the existing selftest uses this pattern, and
> > I'm not sure /proc/config.gz is enabled in the default kernel config.
>
> Yeah and I'm not sure I even like my hacky suggestion here, I mean let's =
be
> honest, it sucks.
>
> >
> > One option is to have ChromeOS or Android to maintain an out-of-tree
> > test, since the configuration will be enabled there.
>
> Nah haha, though of course you can do what you want. Really want somethin=
g
> upstream.
>
> >
> > Option two is to create a new path:
> > tools/testing/selftests/sealsysmap. Then, add
> > CONFIG_SEAL_SYSTEM_MAPPING=3Dy to the config file and add a selftest to
> > this path. This seems to be the preferred way by selftest, but we need
> > a new dir for that.
>
> OK I like option 2 let's do this.
>
> But let's call it mseal_system_mappings (yes I"m being nitty again :) I
> really want to try to _explicitly_ say 'mseal' because we have other form=
s
> of sealing.
>
Sure.

If long path names aren't a problem, I will use mseal_system_mappings,
otherwise mseal_sysmap.

> Not your fault, but we overload terms like _crazy_ in mm and need to be
> cautious as not to confuse vs. e.g. memfd seals.
>
>
> >
> > Option three is to add a self-test when we have a process-level opt-in
> > solution. This would allow the test to deterministically know whether
> > the vdso should be sealed or not.
>
> Yeah one for future.
>
> >
> > >
> > > But anyway, FWIW I think it'd be useful to assert that mremap() or mu=
nmap()
> > > fails here for system mappings for the sake of it. I guess this is, i=
n
> > > effect, only checking mseal-ing works right? But it at least asserts =
the
> > > existence of the thing, and that it behaves.
> > >
> > > Later on, when you add some way of observing that it's enabled or not=
, you
> > > can extend the test to check this.
> >
> > I think it is best that we don't add a test that doesn't actually
> > check the code change. Do you think one of the above three options
> > works ? maybe the second option (with a new path) ?
>
> Yeah I actually agree on reflection. And yes agreed option 2 is great,
> thanks!
>
> >
> > In any case, I think the risk is low, and the code changes are quite
> > simple, and fully tested.
>
> Yeah indeed, but I'd really like _something_ if possible. If option 2 is
> relatively quick let's get that sorted out!
>
Great ! I will work on option 2.

Thanks
-Jeff

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B0261F4C93;
	Fri, 28 Feb 2025 17:31:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1740763862; cv=fail; b=SVAZgpeFgmAHI+cxbp2Vg4xhemLU+ZYPT/vcdug3BnhGNnb7X0fGCu4VxJUUWb/zD1xO8wJu6WZ5nIS7owxp51KK0OKCy8ZAS51O/yQQCJ8++E1gbqn5Lyv7hUJJ7pn36d65ywCpMxOnCypJ7FdPAwVBOTx7iOZdbEn/46GNaY8=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1740763862; c=relaxed/simple;
	bh=cv6TRHQTv9awt99I9Zgzg2ApOCV937kDBFuMxRpZXMc=;
	h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
	 Content-Disposition:In-Reply-To:MIME-Version; b=sQJ80IbGbxyfpZ3XED6ASG1UaguWtF8xEjyuH6ZjCI7Kw4Al1vbkexSvrX9uRMLPT5MtjF1en+8lqlSJSyu8yAEXQU03Buee/nAF9chq2xdUG0Mpi2feb6D7UJP/zEneW7BZflhVsY3nNzYPvHxZLdyIExtonoRgeAqyPy00zcA=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=Aqbo9WBD; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=CeSz1iMF; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="Aqbo9WBD";
	dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="CeSz1iMF"
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
	by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 51SEH42p005714;
	Fri, 28 Feb 2025 17:30:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2023-11-20; bh=cv6TRHQTv9awt99I9Z
	gzg2ApOCV937kDBFuMxRpZXMc=; b=Aqbo9WBDuFLnNlWasnBTRsv/HFBFhN+kny
	m+RcbgzfpOqs1DPpc7k91ZMs7sDllU6VPsZ6mRFy99htGqyZoR+HRlVWJ8ObSS+3
	9206BOexR90CriwCfmAiAi7rKOrW9x9Pum27KPx4MS/WH1RVLDjUEj5Ss5gPTkJF
	qur2IGdr0Ceg9RnvQTMASMvPRVc7RC2iLCqjokNCyFhKjBFY0ZjOS1QUR5QFiG52
	mAM6pIFgkEZU4J0un0/wY784EvIeHxGgph+yCoVXw4T1nmynA7J9ZlumFljUaiMI
	BDesS0OZjfN2xN7UiNRxIZ5v8fiNu+I1BBHnG/DQujaackRZ0BDw==
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232])
	by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 451psce41f-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Fri, 28 Feb 2025 17:30:16 +0000 (GMT)
Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
	by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 51SGwtlH010205;
	Fri, 28 Feb 2025 17:30:15 GMT
Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam04lp2170.outbound.protection.outlook.com [104.47.73.170])
	by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 44y51dkts8-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Fri, 28 Feb 2025 17:30:15 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CDpKWXaF4JYffebUVis3XsX+D7IG7YT3h4qFstjWQ7Qpdh3plcWfZklXgtm1xaiUwB00x8vI+0vDdqUSl4ihZ5P8hs+UsRnEx5sBJ+iC+wNwj4zMjcDDliNnSIW4v/I5JTlSnnftgdwz1V6RvPCVNnERrc9J+9PNEfHqn14b0PccVNICB4WxVffyU/8DwDaSgk+g9/+ws72ad9ZofXWoiLp599ZECvHXeCo8N6gyulZ8osbvSz6PSlsU/xsQlti9q+S2z0H7M98IDV7bqoeyj0ZyS1/n3uOcNRIVYplVXgBB+JJxR1V+98wB4RP3hs1gMVitfQe6pB3vEXmeIx571Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cv6TRHQTv9awt99I9Zgzg2ApOCV937kDBFuMxRpZXMc=;
 b=B43TlnnuozB+nnG4OSKCFodqbd19n1AV9bZPWS53C6HmcoZBkS7JAQnmJ20WewrMiPeRTIgBgQ8lUpfA7dXwxWwIPBHtqT8ERTuz6U6dGBVyMFPpRfIAdT8xNgVWrpS/ILUp6FV75mNv2aB+dE2qrX/h0S5YP9rP5Gh+jHse4KG2nt68gT0zU2v+0WOAPXzzyf8iteBJeGdPaHNyaS4gK6R2slsJ4Xe+6Tb2uoGpmdwStIKUPXGa45so6vqgmA75d7M7eEkFVTq8KTOm53/E6k46xc/ghvSQN2joFxA3z/yX+sN2AaJSkTSl5ZbPEwNzuRgNUJEfnMDGqo3fYTR1aA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cv6TRHQTv9awt99I9Zgzg2ApOCV937kDBFuMxRpZXMc=;
 b=CeSz1iMFiVlOxG/hNPJf37NXoamgoHfw1m78ApoFylcWLLiQNC2jH2WWcX1htjVp98xZDeeePo2d1UTg1RVNj5/VOcc8OULe1BkbJOmx/3Z2cinuGm6uKATtJCCKGm+48NNRX0oJ9nXqnlcSltrGcrY/y4WbVWf8qax6g/AkEgY=
Received: from MN2PR10MB4112.namprd10.prod.outlook.com (2603:10b6:208:11e::33)
 by SA1PR10MB7710.namprd10.prod.outlook.com (2603:10b6:806:3a7::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8489.22; Fri, 28 Feb
 2025 17:30:12 +0000
Received: from MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c]) by MN2PR10MB4112.namprd10.prod.outlook.com
 ([fe80::3256:3c8c:73a9:5b9c%7]) with mapi id 15.20.8489.023; Fri, 28 Feb 2025
 17:30:12 +0000
Date: Fri, 28 Feb 2025 17:30:09 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jeff Xu <jeffxu@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Liam R. Howlett" <Liam.Howlett@oracle.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
        Oleg Nesterov <oleg@redhat.com>, Andrei Vagin <avagin@gmail.com>,
        Benjamin Berg <benjamin@sipsolutions.net>,
        LKML <linux-kernel@vger.kernel.org>,
        "linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>,
        linux-mm@kvack.org, Jorge Lucangeli Obes <jorgelo@chromium.org>,
        Stephen =?utf-8?Q?R=C3=B6ttger?= <sroettger@google.com>,
        "hch@lst.de" <hch@lst.de>, "ojeda@kernel.org" <ojeda@kernel.org>,
        Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>,
        "adobriyan@gmail.com" <adobriyan@gmail.com>,
        "johannes@sipsolutions.net" <johannes@sipsolutions.net>,
        Pedro Falcato <pedro.falcato@gmail.com>,
        "hca@linux.ibm.com" <hca@linux.ibm.com>,
        Matthew Wilcox <willy@infradead.org>,
        "anna-maria@linutronix.de" <anna-maria@linutronix.de>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "Jason@zx2c4.com" <Jason@zx2c4.com>, Helge Deller <deller@gmx.de>,
        Randy Dunlap <rdunlap@infradead.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        Peter Xu <peterx@redhat.com>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "gerg@kernel.org" <gerg@kernel.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>, "ardb@kernel.org" <ardb@kernel.org>,
        "mhocko@suse.com" <mhocko@suse.com>,
        "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "ardb@google.com" <ardb@google.com>, Elliott Hughes <enh@google.com>,
        "rientjes@google.com" <rientjes@google.com>,
        Guenter Roeck <groeck@chromium.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
        Mike Rapoport <mike.rapoport@gmail.com>
Subject: Re: your mail
Message-ID: <a05e6abc-f767-4b29-96fd-1ce055ce8a51@lucifer.local>
References: <20250224225246.3712295-1-jeffxu@google.com>
 <e697ee1d-6075-4f24-8365-32aa4bc84d7e@lucifer.local>
 <CABi2SkXcgB1Zjztqc1W4M-5j9z_wMCRaEtK-wLL3x9_qC1aGHQ@mail.gmail.com>
 <f65bd1bf-4e81-454a-afaa-f84c13cc6227@lucifer.local>
 <CABi2SkV2_-LYGjROm3cs8nHrzBiw7pjpe0i7QGNPsPKHSeajog@mail.gmail.com>
 <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local>
 <CABi2SkX8QM7W0uCUBPFhjrC3psr1HDHLe2i-9hzh81UyKsBuQA@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABi2SkX8QM7W0uCUBPFhjrC3psr1HDHLe2i-9hzh81UyKsBuQA@mail.gmail.com>
X-ClientProxiedBy: LO4P265CA0272.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:37a::12) To MN2PR10MB4112.namprd10.prod.outlook.com
 (2603:10b6:208:11e::33)
Precedence: bulk
X-Mailing-List: linux-hardening@vger.kernel.org
List-Id: <linux-hardening.vger.kernel.org>
List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN2PR10MB4112:EE_|SA1PR10MB7710:EE_
X-MS-Office365-Filtering-Correlation-Id: 38800717-5c0d-4884-f843-08dd581d8e41
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?URhrN/MylfKP39Ge93h6ZDVVz0oLDFEH6HxUoTk9jx47C14SrN0B/Wp6hzW7?=
 =?us-ascii?Q?Jg+fJiNNpyTSMKb+h+UkTd6VkLqwDmOhBuQ6WNI982Fs8x7duNXriiNIxm+H?=
 =?us-ascii?Q?ci4QcHoQGbT59ImnncC4wBpOluqxJUIFWfg0NyeE2SMTqZhN9elvwNr1HZwb?=
 =?us-ascii?Q?GPVp4ytR/Ca6nu0H/Fg9foESBJaIKvFMPyEeqzbhUArC2HXh6s1CP3GnIqju?=
 =?us-ascii?Q?3DxEIKOrpRfxGvj2JUpJO+goGJXYx7+cXXxm2bRqUyHYJJ3gSAcR/TYheS5U?=
 =?us-ascii?Q?52jcOjBZ8cVBJm6b821gsKLaSWhX41WgXfNVzA/Hma3G5naNGf9OBMZZWpZG?=
 =?us-ascii?Q?27KebisqUarM4Sgx+DNgGo0cwQWQfalj/Znrz2hGk4chsebr8hDnaV97Ws2u?=
 =?us-ascii?Q?OLw/dt9DluFozQeWw+iYmlrlOhnQgzaUVD7j6BScfElLf5NqUStLMqWQy1J3?=
 =?us-ascii?Q?jCh6MX4P3mWG6OiJkgNipCvOt/RnOsPCjFHY3lqY9uTUgbIccYrNEn60eB7B?=
 =?us-ascii?Q?dkenbmXREu0OB22ZsFAhcU330vhpjWa835RT/1sbjC0vfRAAPDEmi3H6Eyn3?=
 =?us-ascii?Q?mmvvJc+GIK4OYbWcyHHBW9En/nenImYCLwV8pD5IYR09p1SEa4yIIkYosXF/?=
 =?us-ascii?Q?y6tD1NSSAke6NmIPNv/wXrcsht86e9rAZrogO7eAUQ17lMi6mY+Pv7HcNMRv?=
 =?us-ascii?Q?n0EFANKk76JdI4h7HyWAw4Ll7pkRN3mS41+bDWrAC0UiX2bFAP/duhYjL0ss?=
 =?us-ascii?Q?WmABNgLlYVMfs1OHjnih/bCr/p2DWvVAGOOJ2U2JjV5c0a6bq9f8+ZEclbDp?=
 =?us-ascii?Q?daxyxGUS/Ljdi0jk/kfSiIfD6y94JlrBSWhj7JPs0NA2XR2MUgjqcUs6LHqH?=
 =?us-ascii?Q?WvzKfS581V+uFGd33nnqQmNetocL53gChyjPSXQGmac+fLKZMwXaQ9mEzHpU?=
 =?us-ascii?Q?pytReNWUkLYUSLn5lLa5h8jZXbUBT+cUfoXdQw1rRhqKOegKZ1uCcNSXthC7?=
 =?us-ascii?Q?pMGT12WDiIXycKYjkI7T6UMNuMf3oz2gke1HgmLxCEa89w7ilAGX+KJzsF9m?=
 =?us-ascii?Q?9+sN6ZqjbuC8yj34/JRNfyuphyLhwcPjyCuvyx6o0hEztEcmltSuP+CFDRN/?=
 =?us-ascii?Q?3PES5iwl8iJeg4jb0q6QXOCetuzQ5kgaDh+MgpISFjntI8mP+UNCjxLjyeOw?=
 =?us-ascii?Q?xRlruxnMCJ2WF+dNd2EUXgBJ5nXKb+N7o7mhmIGDBudsmGMKn/oTa4qU3S+W?=
 =?us-ascii?Q?ojoW0Bq/NQ0tv2SByT+bYKWODRiCkMfe9jH1tL42FSrtasvy4v61g3jUJW6I?=
 =?us-ascii?Q?54p/48+cw7/t6gJE2iW8a7usyTeu/1T9Y7Vu9heYPVRUKMJk2U/tFZsM0ePd?=
 =?us-ascii?Q?kLyvAs8qhS4ONFMrrgilRDzUHTkm?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB4112.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?zbfmCe39OCFvSFJsnyXtaY8bcVl1P/DVHlg9yS9vYNcSlJZbTnjDVyHiB2fk?=
 =?us-ascii?Q?wY5oYhqwnKLGpK3izIjtfRfXhp7Do9I9dCnzlpyQ9Chf4a23CQs5KVHCqsdo?=
 =?us-ascii?Q?XIy76L5kO3VKGhWidLlQ1vTSjzduU9I+/zSwZVyDzS6DHVNg9q3O+8lVT+d6?=
 =?us-ascii?Q?giCb2XVYUyLbAZ1M9yTLFBWP06kA0d1Rmg8C8r+uSBeI+O3GKhz8IbIPu97i?=
 =?us-ascii?Q?dOG6PwaOjBqKkdasgESNYEjk+AUwgd9YSOPRf9u1BwjXbKy/kIFTwiPjIEMo?=
 =?us-ascii?Q?T8Xnr15yePmAk5e4qdHzgtkIcpYkymMTgvMuhZ0tdS7uaOdfVkIwl9CqmnZM?=
 =?us-ascii?Q?ovVEasJ6zcXmJWgffoU4bAYxKLivA/CK1b1v5BDozUBsq0ZnIRfLaITnmz2J?=
 =?us-ascii?Q?ID4DlpUCPmfepSYRSIAWtPjZTIyPpwFBC5blX1zF1kyLguqKlnd+e7FMNHRx?=
 =?us-ascii?Q?TWIq320dmKv5EK9UGdrevANDf803Ed0DJjxfAwf0DHoKlNd5ZC6sfh3iDek4?=
 =?us-ascii?Q?fNjRtBG4BZW/rx5pxSRoQndvUHN6dA80GICvD548dPFeUQ5bgoIOQyIahzIG?=
 =?us-ascii?Q?Bo6oWcxdd+igqyEIYQMPJfCo7lhjNCGINTL3C3d/EvFdD6s95Wwv2TbIOOTo?=
 =?us-ascii?Q?ZiqTgvUC3OiqDSVIe/z6IGCRcUvhfPkVfYcNL7CxOJrvo60Cd0F8pLsBFJEB?=
 =?us-ascii?Q?MUy1PJJGzzgLMxoGpPKnpPHt5ptFbYIbxKn+p/2tIXYIXbOwQ0fwK6XPY8Kn?=
 =?us-ascii?Q?8kQXicCAGHZIQafSiQ9gK1+uXRS2Yze4apEEjePmC7vde9nsqzF/67WgdEql?=
 =?us-ascii?Q?lCfdDEUAMbbV45MHiUB/4sP2c+vYcJ1Qm9SUxBGvLa6vqeMwl4v0DQHd8s8R?=
 =?us-ascii?Q?6Xbowz5afPrKQ5RO8KAd8VTlQUKkpWfRKOEygvSTY8Pv8UQnqdcdNLkFw0u7?=
 =?us-ascii?Q?7yMXx0ivPyo/jmnIk527nvsuWF4Kn1Iz8uKXWjju3tUh9OK9a8U7+J8xVOhu?=
 =?us-ascii?Q?vnb8FD48uBkDmViELB7aZrnn2PBOji/7JxKGclKzfT6Qf72OQYmE1Ang49Kt?=
 =?us-ascii?Q?ekZT7pMhFBZkJU8kexokrZ9OFq+db14MKVHx430j0DIfkqZR02rnrIVAf3S6?=
 =?us-ascii?Q?BIzKisx3I938jhuyqDwxRaOo7hfBXapjxyyCwCdI77p2Uhu1aHeAAB2kI9e2?=
 =?us-ascii?Q?TB1NT1AZMpfebtlcU534Rl8IVahuyBzqqX17vKKUIArbAEa2dzDcg6X6DZbR?=
 =?us-ascii?Q?FtqMNZb2riUD1c9KSOR6dhFmSl2wP+aFwpFBzQa5YJC1mwgnU2k3U3r/BZWr?=
 =?us-ascii?Q?BNaJfzjVttznXZSf0rfA45zg+byiyBoqaZfJ888RGVa4KnoGlzROM4+47Hm0?=
 =?us-ascii?Q?f3EU1fXXvX63J9sU3mVKcP9ecnX+3jRt5vE48XQpp5L44r14xJ8A8hi+QSHX?=
 =?us-ascii?Q?W5jYMIe6VDxc2NYzC4HaTsHY0EJUjd8P0uoQ7a1e/fXrWxP14KKnNY05CPBX?=
 =?us-ascii?Q?LOA0ZKPIt6iZubOw2JUzQDWqAH0yG3t/qt/CxCrYvXkIUW+9Ch5u8fdGVUQH?=
 =?us-ascii?Q?mo3nqYWbhMlnZkQYk6XP4ecdlopmgt4KN2ImkX6Abibhh5LiE8CWYKuQwS9T?=
 =?us-ascii?Q?jQ=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	 
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38800717-5c0d-4884-f843-08dd581d8e41
X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4112.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2025 17:30:12.1597
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7PNr4rcgvyn05b+UNzzCsCtVKuCIQfJs/WAd8l9YT/LUU76V+wt9h4gF28OdoFA+n5ZsFRXynYjhcO9UztnmJONVRIMa1OC1Umc7U/UTjQY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB7710
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-02-28_05,2025-02-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0
 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2502100000 definitions=main-2502280128
X-Proofpoint-GUID: N6DeDMTT8NOThdYAv6jTrGNNBWXJF8tS
X-Proofpoint-ORIG-GUID: N6DeDMTT8NOThdYAv6jTrGNNBWXJF8tS

On Fri, Feb 28, 2025 at 09:24:11AM -0800, Jeff Xu wrote:

[snip]

> > >
> > > When the vdso is marked with "sl", mremap() will fail, that's part of
> > > the mseal() business logic and belongs in mseal_test. The mseal_test
> > > already covers the mseal, and this series doesn't change mseal.
> > >
> > > As for the "sl", as I responded in the "refactor mseal_test" [1] , it
> > > will be part of the verifying step:
> > >
> > > [1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17mGy-XutSTAwg@mail.gmail.com/
> >
> > OK cool thanks. I will look at this when I can, I'm just snowed under
> > pre-LSF and have been sick so backlog, backlog as discussed off-list. But
> > it's not been forgotten (whiteboard etc. etc.)
> >
> Ya, no worry about that review, please take time to recover, I will wait.
> And appreciate your time and take priority for reviewing this series.

Thanks :)

[snip]

> > >
> > > Option two is to create a new path:
> > > tools/testing/selftests/sealsysmap. Then, add
> > > CONFIG_SEAL_SYSTEM_MAPPING=y to the config file and add a selftest to
> > > this path. This seems to be the preferred way by selftest, but we need
> > > a new dir for that.
> >
> > OK I like option 2 let's do this.
> >
> > But let's call it mseal_system_mappings (yes I"m being nitty again :) I
> > really want to try to _explicitly_ say 'mseal' because we have other forms
> > of sealing.
> >
> Sure.

Thanks!

>
> If long path names aren't a problem, I will use mseal_system_mappings,
> otherwise mseal_sysmap.

I think long form is fine.

[snip]

> > >
> > > In any case, I think the risk is low, and the code changes are quite
> > > simple, and fully tested.
> >
> > Yeah indeed, but I'd really like _something_ if possible. If option 2 is
> > relatively quick let's get that sorted out!
> >
> Great ! I will work on option 2.

Perfect cheers!

>
> Thanks
> -Jeff

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=/0NN=QP=quicinc.com=quic_akhilpo@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id B4C9EC35FEE
	for <linux-firmware@archiver.kernel.org>; Tue, 17 Sep 2024 08:03:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix)
	id 8434FC4CEC7; Tue, 17 Sep 2024 08:03:40 +0000 (UTC)
Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.kernel.org (Postfix) with ESMTPS id 60105C4CEC6
	for <linux-firmware@kernel.org>; Tue, 17 Sep 2024 08:03:39 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.kernel.org 60105C4CEC6
Authentication-Results: smtp.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.kernel.org; spf=pass smtp.mailfrom=quicinc.com
Received: from pps.filterd (m0279866.ppops.net [127.0.0.1])
	by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 48H5jCPm022178;
	Tue, 17 Sep 2024 08:03:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
	cc:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=qcppdkim1; bh=LvbBWrsiGIYhO96i+cXBfmc4
	/PmRTphe22qERmtzppE=; b=oRFpEezDFi78MPQU1rjlTTNHFyK2Dk9EqcJB4dws
	LkH0v9z70DPAoYjBaE5ZF2Me2mSNjxyJCGD2rVYsUa7gw/J6ghLvw/5V8oxqGz83
	S1tWno4+3zqOtOjIfTw/fN48rrx/AGJJJczsSuSPXxtAXcKQlYKDDwye3w6F7bEV
	pMm5M8tQV5juuFpJHsL59tQpF+CPc8M7WgYhRhF5n91HA03UGrfKEFfk9m8AKkrP
	vzkElr3mpEhABjYZDfHA34Tsg5lCt3DKwPXc+MzKhG5jXJGv7FDYTRvTu88941z8
	o9HP2Y9Huq2b2/sVPBw+E4MiJXup128mLs/hkV7iBdyb8w==
Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20])
	by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 41n4jdp77e-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Tue, 17 Sep 2024 08:03:32 +0000 (GMT)
Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196])
	by NALASPPMTA03.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 48H83VFe001361
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Tue, 17 Sep 2024 08:03:31 GMT
Received: from hu-akhilpo-hyd.qualcomm.com (10.80.80.8) by
 nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.1544.9; Tue, 17 Sep 2024 01:03:30 -0700
Date: Tue, 17 Sep 2024 13:33:26 +0530
From: Akhil P Oommen <quic_akhilpo@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
List-Id: <linux-firmware.lore.kernel.org>
CC: <linux-firmware@kernel.org>, <quic_rajeshk@quicinc.com>
Subject: Re: your mail
Message-ID: <20240917080326.vpks3w3dmhgn5aiq@hu-akhilpo-hyd.qualcomm.com>
References: <20240917071016.gp43cuysm4kdznzx@hu-akhilpo-hyd.qualcomm.com>
 <CAA8EJpp4tGH_v7z9Um7Y+xxWPyFFMq4P3-cytNSJe3dqhLD_OA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAA8EJpp4tGH_v7z9Um7Y+xxWPyFFMq4P3-cytNSJe3dqhLD_OA@mail.gmail.com>
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To
 nalasex01a.na.qualcomm.com (10.47.209.196)
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-ORIG-GUID: Yo_8YrJXy2q9F82Ru6Y6tivkIznLPl1v
X-Proofpoint-GUID: Yo_8YrJXy2q9F82Ru6Y6tivkIznLPl1v
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29
 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0
 clxscore=1015 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0
 priorityscore=1501 spamscore=0 bulkscore=0 lowpriorityscore=0
 mlxlogscore=269 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2408220000 definitions=main-2409170059

On Tue, Sep 17, 2024 at 09:24:19AM +0200, Dmitry Baryshkov wrote:
> On Tue, 17 Sept 2024 at 09:10, Akhil P Oommen <quic_akhilpo@quicinc.com> wrote:
> >
> > The following changes since commit 6c88d9b8253b8ec6df701a551a56438ea2e5bacf:
> >
> >   Merge branch 'amd-staging' into 'main' (2024-09-13 20:28:50 +0000)
> >
> > are available in the Git repository at:
> >
> >   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git gpu-fw-SA8775p
> >
> > for you to fetch changes up to 43c971bcd74d9793140a8fbbcc805204cb797f96:
> >
> >   qcom: add gpu firmwares for sa8775p chipset (2024-09-17 11:57:51 +0530)
> >
> > ----------------------------------------------------------------
> > Akhil P Oommen (1):
> >       qcom: add gpu firmwares for sa8775p chipset
> >
> >  WHENCE                    |   2 ++
> >  qcom/a663_gmu.bin         | Bin 0 -> 55892 bytes
> >  qcom/sa8775p/a663_zap.mbn | Bin 0 -> 1054680 bytes
> >  3 files changed, 2 insertions(+)
> >  create mode 100644 qcom/a663_gmu.bin
> >  create mode 100644 qcom/sa8775p/a663_zap.mbn
> 
> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Sent it out sooner without a subject due to a 'Mutt' fiasco. Please excuse
me for the missing subject.

Hope this is sufficient to pull the firmwares.

-Akhil

> 
> Thank you!
> 
> -- 
> With best wishes
> Dmitry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=5j3L=QP=linaro.org=dmitry.baryshkov@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id 041A1C3601A
	for <linux-firmware@archiver.kernel.org>; Tue, 17 Sep 2024 14:13:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix)
	id B3B45C4CECD; Tue, 17 Sep 2024 14:13:27 +0000 (UTC)
Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by smtp.kernel.org (Postfix) with ESMTPS id 923C8C4CEC5
	for <linux-firmware@kernel.org>; Tue, 17 Sep 2024 14:13:26 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.kernel.org 923C8C4CEC5
Authentication-Results: smtp.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2f761461150so61311561fa.0
        for <linux-firmware@kernel.org>; Tue, 17 Sep 2024 07:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1726582405; x=1727187205; darn=kernel.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=20CNLvOyUUOXoU+FkRSTMZDwqqaWT7yX2cgwiXTVbpo=;
        b=usliAyZKvTNu0Svd3dzRs4q4c09VTsjCh8TgtqwRP5a8G/CTLJnZnSNaubqnmJWfoW
         9Wy9HooT9YY3Maqf2D+bvMU62Tl+ThCzSFnSWbkO4kdvhOxWL7Sq4GbnO7qIQGKP/RON
         U0QVYgojkZpJdUqKe24LtajEJuyoP+upjDgVNjxSy2jbhH5ib6YPdtbbABIUPT24zOzH
         P7ssQG/ElanpLGd7bRv9N4WHP+xZDgnyaFd/w74LfBjJUxF43Y0ZaHMroTcXs/F2vcza
         vkCWsjDKzz6xmG0e/fWrSy4q+/tWlsSf4pXwh19xfi69VDJRyIkoxwRroCbkpwLLbRZP
         r0Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1726582405; x=1727187205;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=20CNLvOyUUOXoU+FkRSTMZDwqqaWT7yX2cgwiXTVbpo=;
        b=WEqL+k72mzeD0EKiOO7RTvV8FhfOrHcpuW/YGQ37k1gLWP8jkUVZ9Os0V73MT8MwMN
         5nahqj5fXeIWyasrg7EkanGCh2Obt/ZpW1eFi7lYXRT6uKB4G794aQz+9LqIhwLGhLre
         yIlR5p2suFT10mc3fAIZeSR/iDxA8wSGTs4a3VSjfwjezUd6xFS/mpL/+3DEjhYhDPhi
         IGQZWZ/qu/PxoC7Aqjku7StNSk7EJj159gUmD9SRaAU5Jb9GPz9dSeVGwFmUo6Mip+33
         uTmMiTxFukE+tK/1TxOdB9QfmF12FFioVei4Db55crnDpYyqQUm3c7/iX26tH49hU7Pf
         zyRA==
X-Gm-Message-State: AOJu0YxdoKm/AB3bQFv2Opg8cnAvb/Slk4aAc1kRl1K2IkDyDuyKrCzT
	EVqrJqrzy++SirWL0KLi7LA0D5agl7tQV8xWs16LcljPl7I1xFN9ojGhdFNx8/0=
X-Google-Smtp-Source: AGHT+IF3ANdFFNjkMP69lAqM1H3KxfGPX7iDKp4IsjBTwV6kB1b0WX/YZIbOF6JWiiZdNrPjBu7EVw==
X-Received: by 2002:a05:6512:a8e:b0:52c:e17c:cd7b with SMTP id 2adb3069b0e04-5367fed250bmr10763816e87.22.1726582404391;
        Tue, 17 Sep 2024 07:13:24 -0700 (PDT)
Received: from eriador.lumag.spb.ru (2001-14ba-a0c3-3a00--7a1.rev.dnainternet.fi. [2001:14ba:a0c3:3a00::7a1])
        by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-536870966basm1204640e87.138.2024.09.17.07.13.23
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 17 Sep 2024 07:13:23 -0700 (PDT)
Date: Tue, 17 Sep 2024 17:13:22 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Akhil P Oommen <quic_akhilpo@quicinc.com>
List-Id: <linux-firmware.lore.kernel.org>
Cc: linux-firmware@kernel.org, quic_rajeshk@quicinc.com
Subject: Re: your mail
Message-ID: <gmss4xrecjq4pyuoggpoa35suetarsmcx5vfl3nc75ous2hhbl@zej5qjjkd2oz>
References: <20240917071016.gp43cuysm4kdznzx@hu-akhilpo-hyd.qualcomm.com>
 <CAA8EJpp4tGH_v7z9Um7Y+xxWPyFFMq4P3-cytNSJe3dqhLD_OA@mail.gmail.com>
 <20240917080326.vpks3w3dmhgn5aiq@hu-akhilpo-hyd.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240917080326.vpks3w3dmhgn5aiq@hu-akhilpo-hyd.qualcomm.com>

On Tue, Sep 17, 2024 at 01:33:26PM GMT, Akhil P Oommen wrote:
> On Tue, Sep 17, 2024 at 09:24:19AM +0200, Dmitry Baryshkov wrote:
> > On Tue, 17 Sept 2024 at 09:10, Akhil P Oommen <quic_akhilpo@quicinc.com> wrote:
> > >
> > > The following changes since commit 6c88d9b8253b8ec6df701a551a56438ea2e5bacf:
> > >
> > >   Merge branch 'amd-staging' into 'main' (2024-09-13 20:28:50 +0000)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git gpu-fw-SA8775p
> > >
> > > for you to fetch changes up to 43c971bcd74d9793140a8fbbcc805204cb797f96:
> > >
> > >   qcom: add gpu firmwares for sa8775p chipset (2024-09-17 11:57:51 +0530)
> > >
> > > ----------------------------------------------------------------
> > > Akhil P Oommen (1):
> > >       qcom: add gpu firmwares for sa8775p chipset
> > >
> > >  WHENCE                    |   2 ++
> > >  qcom/a663_gmu.bin         | Bin 0 -> 55892 bytes
> > >  qcom/sa8775p/a663_zap.mbn | Bin 0 -> 1054680 bytes
> > >  3 files changed, 2 insertions(+)
> > >  create mode 100644 qcom/a663_gmu.bin
> > >  create mode 100644 qcom/sa8775p/a663_zap.mbn
> > 
> > Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> 
> Sent it out sooner without a subject due to a 'Mutt' fiasco. Please excuse
> me for the missing subject.
> 
> Hope this is sufficient to pull the firmwares.

I think the pull request didn't hit the mailing list. At least I don't
see it in the archives on lore.

-- 
With best wishes
Dmitry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-hwmon-owner@vger.kernel.org>
Received: from mail-pf0-f195.google.com ([209.85.192.195]:35833 "EHLO
        mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752414AbdLGXeD (ORCPT
        <rfc822;linux-hwmon@vger.kernel.org>); Thu, 7 Dec 2017 18:34:03 -0500
Received: by mail-pf0-f195.google.com with SMTP id j124so5863994pfc.2
        for <linux-hwmon@vger.kernel.org>; Thu, 07 Dec 2017 15:34:03 -0800 (PST)
Date: Thu, 7 Dec 2017 15:34:01 -0800
From: Guenter Roeck <linux@roeck-us.net>
To: Paul Marques Mota <paul@marquesmota.pt>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: your mail
Message-ID: <20171207233401.GB12517@roeck-us.net>
References: <20171207213201.rorchhbd63gzlekb@marquesmota.pt>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171207213201.rorchhbd63gzlekb@marquesmota.pt>
Sender: linux-hwmon-owner@vger.kernel.org
List-Id: linux-hwmon@vger.kernel.org

On Thu, Dec 07, 2017 at 09:32:01PM +0000, Paul Marques Mota wrote:
> From: Paul Marques Mota <paul@marquesmota.pt>
> To: HARDWARE MONITORING <linux-hwmon@vger.kernel.org>
> Date: Thu, 7 Dec 2017 20:04:22 +0000
> Subject: [PATCH] add stack trace to deprecated hwmon_device_register()
> 
> Hi,
> 
> hwmon_device_register() in drivers/hwmon/hwmon.c prints the unhelpful
> message below on my machine:
> 
> (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
> 
> Therefore, this patch dumps the stack at that point. In my case it is
> then obvious in the resulting dmesg, available at
> 
> http://www.marquesmota.pt/dmesg.txt
> 
> that thermal_add_hwmon_sysfs() in drivers/thermal/thermal_hwmon.c needs
> to be converted to the new API.
> 
> This patch is against 4.15.0-rc2
> I believe it is also needed in Bugzilla bug #195843
> https://bugzilla.kernel.org/show_bug.cgi?id=195843
> 
> Signed-off-by: Paul Marques Mota<paul@marquesmota.pt>

Nack, this is not needed. The thermal subsystem is the only subsystem
which doesn't pass a device pointer, and I don't want to have logs
clogged up with unnecessary tracebacks because of it.

If it wasn't for thermal, I would actually let hwmon registrations with
NULL device pointer fail completely. Unfortunately there is no easy way
to convert the thermal subsystem to use hwmon_device_register_with_info(),
since even though thermal_zone_device_register() registers a thermal zone
device, it does not have a notion of 'struct device *'.

Maybe someone can step in and convert the thermal code to use
hwmon_device_register_with_groups(). That doesn't really solve the problem,
but at least the symptom would be gone, and the thermal code would be
a little cleaner.

Guenter

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-hwmon-owner@vger.kernel.org>
Received: from casa.marquesmota.pt ([163.172.49.138]:42894 "EHLO
        casa.marquesmota.pt" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750973AbdLGXiE (ORCPT
        <rfc822;linux-hwmon@vger.kernel.org>); Thu, 7 Dec 2017 18:38:04 -0500
Subject: Re: your mail
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
References: <20171207213201.rorchhbd63gzlekb@marquesmota.pt>
 <20171207233401.GB12517@roeck-us.net>
From: Paul Marques Mota <paul@marquesmota.pt>
Message-ID: <35218213-d611-1ad2-6260-942218f818d0@marquesmota.pt>
Date: Thu, 7 Dec 2017 23:38:01 +0000
MIME-Version: 1.0
In-Reply-To: <20171207233401.GB12517@roeck-us.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-hwmon-owner@vger.kernel.org
List-Id: linux-hwmon@vger.kernel.org

Le 07/12/2017 Ă  23:34, Guenter Roeck a ĂŠcritÂ :

> Nack, this is not needed.

Ok, thank you for the quick answer.

> Guenter

Regards,

-- 
Paul


From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Richard B. Johnson" <root@chaos.analogic.com>
Subject: Re: your mail
Date: Thu, 19 Feb 2004 09:12:02 -0500 (EST)
Sender: linux-kernel-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.53.0402190907470.30108@chaos>
References: <20040219135212.34779.qmail@web12607.mail.yahoo.com>
Reply-To: root@chaos.analogic.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-path: <linux-kernel-owner+linux-kernel=40quimby.gnus.org@vger.kernel.org>
In-Reply-To: <20040219135212.34779.qmail@web12607.mail.yahoo.com>
To: Joilnen Leite <pidhash@yahoo.com>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
List-Id: linux-ide@vger.kernel.org

On Thu, 19 Feb 2004, Joilnen Leite wrote:

> excuse me friends shcedule_timeout(1) is not a problem
> for spin_lock_irqsave ?
>
> drivers/scsi/ide-scsi.c:897
>
> spin_lock_irqsave(&ide_lock, flags);
> while (HWGROUP(drive)->handler) {
>        HWGROUP(drive)->handler = NULL;
>        schedule_timeout(1);
> }
>
> pub 1024D/5139533E Joilnen Batista Leite
> F565 BD0B 1A39 390D 827E 03E5 0CD4 0F20 5139 533E

What kernel version?  It is very bad. You can't sleep with
a spin-lock being held!

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an Intel Pentium III machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: your mail
Date: Wed, 14 Apr 2010 16:16:04 -0700
Message-ID: <20100414231604.GA12281@core.coreip.homeip.net>
References: <20100414125234.23507.42816.stgit@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-input-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20100414125234.23507.42816.stgit@localhost.localdomain>
Sender: linux-input-owner@vger.kernel.org
To: Alan Cox <alan@linux.intel.com>
Cc: linux-i2c@vger.kernel.org, khali@linux-fr.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
List-Id: linux-i2c@vger.kernel.org

On Wed, Apr 14, 2010 at 01:54:02PM +0100, Alan Cox wrote:
> Subject: [FOR COMMENT] cy8ctmg110 for review
> 
> From: Samuli Konttila <samuli.konttila@aavamobile.com>
> 
> Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
> devices.
> 
> (Some clean up by Alan Cox)
> 
> (No signed off, not yet ready to go in)
> ---
> 
>  drivers/input/touchscreen/Kconfig         |   12 +
>  drivers/input/touchscreen/Makefile        |    3 
>  drivers/input/touchscreen/cy8ctmg110_ts.c |  521 +++++++++++++++++++++++++++++
>  3 files changed, 535 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
> 
> 
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index b3ba374..89a3eb1 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called tps6507x_ts.
>  
> +config TOUCHSCREEN_CY8CTMG110
> +	tristate "cy8ctmg110 touchscreen"
> +	depends on I2C
> +	help
> +	  Say Y here if you have a cy8ctmg110 touchscreen capacitive
> +	  touchscreen
> +
> +	  If unsure, say N.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called cy8ctmg110_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index dfb7239..c7acb65 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -1,5 +1,5 @@
>  #
> -# Makefile for the touchscreen drivers.
> +# Makefile for the touchscreen drivers.mororor
>  #
>  
>  # Each configuration option enables a list of files.
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879)	+= ad7879.o
>  obj-$(CONFIG_TOUCHSCREEN_ADS7846)	+= ads7846.o
>  obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC)	+= atmel_tsadcc.o
>  obj-$(CONFIG_TOUCHSCREEN_BITSY)		+= h3600_ts_input.o
> +obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110)    += cy8ctmg110_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)	+= dynapro.o
>  obj-$(CONFIG_TOUCHSCREEN_GUNZE)		+= gunze.o
>  obj-$(CONFIG_TOUCHSCREEN_EETI)		+= eeti_ts.o
> diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
> new file mode 100644
> index 0000000..4adbe87
> --- /dev/null
> +++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
> @@ -0,0 +1,521 @@
> +/*
> + * cy8ctmg110_ts.c Driver for cypress touch screen controller
> + * Copyright (c) 2009 Aava Mobile
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/input.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <asm/io.h>
> +#include <linux/i2c.h>
> +#include <linux/timer.h>
> +#include <linux/gpio.h>
> +#include <linux/hrtimer.h>
> +
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <asm/uaccess.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +
> +#define CY8CTMG110_DRIVER_NAME      "cy8ctmg110"
> +
> +
> +/*HW definations*/
> +#define CY8CTMG110_RESET_PIN_GPIO   43
> +#define CY8CTMG110_IRQ_PIN_GPIO     59
> +#define CY8CTMG110_I2C_ADDR         0x38
> +#define CY8CTMG110_I2C_ADDR_EXT     0x39
> +#define CY8CTMG110_I2C_ADDR_        0x2	/*i2c address first sample */
> +#define CY8CTMG110_I2C_ADDR__       53	/*i2c address to FW where irq support missing */
> +#define CY8CTMG110_TOUCH_IRQ        21
> +#define CY8CTMG110_TOUCH_LENGHT     9787
> +#define CY8CTMG110_SCREEN_LENGHT    8424
> +
> +
> +/*Touch coordinates*/
> +#define CY8CTMG110_X_MIN        0
> +#define CY8CTMG110_Y_MIN        0
> +#define CY8CTMG110_X_MAX        864
> +#define CY8CTMG110_Y_MAX        480
> +
> +
> +/*cy8ctmg110 registers defination*/
> +#define CY8CTMG110_TOUCH_WAKEUP_TIME   0
> +#define CY8CTMG110_TOUCH_SLEEP_TIME    2
> +#define CY8CTMG110_TOUCH_X1            3
> +#define CY8CTMG110_TOUCH_Y1            5
> +#define CY8CTMG110_TOUCH_X2            7
> +#define CY8CTMG110_TOUCH_Y2            9
> +#define CY8CTMG110_FINGERS             11
> +#define CY8CTMG110_GESTURE             12
> +#define CY8CTMG110_REG_MAX             13
> +
> +#define CY8CTMG110_POLL_TIMER_DELAY  1000*1000*100
> +#define TOUCH_MAX_I2C_FAILS          50
> +
> +/* Scale factors for coordinates */
> +#define X_SCALE_FACTOR 9387/8424
> +#define Y_SCALE_FACTOR 97/100
> +
> +/* For tracing */
> +static int g_y_trace_coord = 0;
> +module_param(g_y_trace_coord, int, 0600);
> +
> +/* Polling mode */
> +static int polling = 0;
> +module_param(polling, int, 0);
> +MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
> +
> +
> +/*
> + * The touch position structure.
> + */
> +struct ts_event {
> +	int x1;
> +	int y1;
> +	int x2;
> +	int y2;
> +	bool event_sended;
> +};
> +
> +/*
> + * The touch driver structure.
> + */
> +struct cy8ctmg110 {
> +	struct input_dev *input;
> +	char phys[32];
> +	struct ts_event tc;
> +	struct i2c_client *client;
> +	bool pending;
> +	spinlock_t lock;
> +	bool initController;
> +	bool sleepmode;
> +	int i2c_fail_count;
> +	struct hrtimer timer;
> +};
> +
> +/*
> + * cy8ctmg110_poweroff is the routine that is called when touch hardware 
> + * will powered off
> + */
> +static void cy8ctmg110_power(bool poweron)
> +{
> +	if (poweron)
> +		gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
> +	else
> +		gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
> +}
> +
> +/*
> + * cy8ctmg110_write_req write regs to the i2c devices
> + * 
> + */
> +static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
> +		unsigned char len, unsigned char *value)
> +{
> +	struct i2c_client *client = tsc->client;
> +	unsigned int ret;
> +	unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
> +	struct i2c_msg msg[] = {
> +			{client->addr, 0, len + 1, i2c_data},
> +			};
> +
> +	i2c_data[0] = reg;
> +	memcpy(i2c_data + 1, value, len);
> +
> +	ret = i2c_transfer(client->adapter, msg, 1);
> +	if (ret != 1) {
> +		printk("cy8ctmg110 touch : i2c write data cmd failed \n");
> +		return ret;
> +	}
> +	return 0;
> +}
> +
> +/*
> + * cy8ctmg110_read_req read regs from i2c devise
> + * 
> + */
> +
> +static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
> +		unsigned char *i2c_data, unsigned char len, unsigned char cmd)
> +{
> +	struct i2c_client *client = tsc->client;
> +	unsigned int ret;
> +	unsigned char regs_cmd[2] = { 0, 0 };
> +	struct i2c_msg msg1[] = {
> +		{client->addr, 0, 1, regs_cmd},
> +	};
> +	struct i2c_msg msg2[] = {
> +		{client->addr, I2C_M_RD, len, i2c_data},
> +	};
> +
> +	regs_cmd[0] = cmd;
> +
> +	/* first write slave position to i2c devices */
> +	ret = i2c_transfer(client->adapter, msg1, 1);
> +	if (ret != 1) {
> +		tsc->i2c_fail_count++;
> +		return ret;
> +	}
> +
> +	/* Second read data from position */
> +	ret = i2c_transfer(client->adapter, msg2, 1);
> +	if (ret != 1) {
> +		tsc->i2c_fail_count++;
> +		return ret;
> +	}
> +	return 0;
> +}
> +
> +/*
> + * cy8ctmg110_send_event delevery touch event to the userpace
> + * function use normal input interface
> + */
> +static void cy8ctmg110_send_event(void *tsc)
> +{
> +	struct cy8ctmg110 *ts = tsc;
> +	struct input_dev *input = ts->input;
> +	u16 x, y;
> +	u16 x2, y2;
> +
> +	x = ts->tc.x1;
> +	y = ts->tc.y1;
> +
> +	if (ts->tc.event_sended == false) {

We set "event_sended" to false immediately before calling
cy8ctmg110_send_event() so I do not see the point of this flag.

> +		input_report_key(input, BTN_TOUCH, 1);
> +		ts->pending = true;
> +		x2 = (u16) (y * X_SCALE_FACTOR);
> +		y2 = (u16) (x * Y_SCALE_FACTOR);
> +		input_report_abs(input, ABS_X, x2);
> +		input_report_abs(input, ABS_Y, y2);
> +		input_sync(input);
> +		if (g_y_trace_coord)
> +			printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);

Do we really need this? Seems to be early development diagnostic.

> +	}
> +
> +}
> +
> +/*
> + * cy8ctmg110_touch_pos check touch position from i2c devices
> + * 
> + */
> +static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
> +{
> +	unsigned char reg_p[CY8CTMG110_REG_MAX];
> +	int x, y;
> +
> +	memset(reg_p, 0, CY8CTMG110_REG_MAX);
> +
> +	/*Reading coordinates */
> +	if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
> +		return -EIO;
> +		
> +	y = reg_p[2] << 8 | reg_p[3];
> +	x = reg_p[0] << 8 | reg_p[1];
> +		/*number of touch */
> +	if (reg_p[8] == 0) {
> +		if (tsc->pending == true) {
> +			struct input_dev *input = tsc->input;
> +
> +			input_report_key(input, BTN_TOUCH, 0);
> +			tsc->tc.event_sended = true;
> +			tsc->pending = false;
> +		}

Just do input_report_key(input, BTN_TOUCH, 0); and let input core take
care of filtering duplicates. This will allow you get rid of bunch of
flags. Also input_sync() is missing here.

> +	} else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
> +		tsc->tc.y1 = y;
> +		tsc->tc.x1 = x;
> +		tsc->tc.event_sended = false;
> +		cy8ctmg110_send_event(tsc);
> +	}
> +	return 0;
> +}
> +
> +/*
> + * if interrupt isn't in use the touch positions can reads by polling
> + * 
> + */
> +static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
> +{
> +	struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&ts->lock, flags);
> +
> +	cy8ctmg110_touch_pos(ts);
> +	if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
> +		hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
> +

So device simply dies after so many errors?

> +	spin_unlock_irqrestore(&ts->lock, flags);

The timer handler is the only user for the spinlock, what is the point?

> +	return HRTIMER_NORESTART;
> +}
> +
> +/*
> + * 
> + */
> +static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
> +{
> +	unsigned char reg_p[3];
> +
> +	if (ts->sleepmode == true) {
> +		reg_p[0] = 0x00;
> +		reg_p[1] = 0xff;
> +		reg_p[2] = 5;
> +	} else {
> +		reg_p[0] = 0x10;
> +		reg_p[1] = 0xff;
> +		reg_p[2] = 0;
> +	}
> +
> +	if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
> +		return false;
> +
> +	ts->initController = true;
> +	return true;
> +}
> +
> +/*
> + * cy8ctmg110_irq_handler irq handling function
> + * 
> + */
> +
> +static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
> +{
> +	struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
> +
> +	if (tsc->initController == false) {
> +		if (cy8ctmg110_set_sleepmode(tsc) == true)
> +			tsc->initController = true;
> +	} else
> +		cy8ctmg110_touch_pos(tsc);

Initalizing device from interrupt handler is quite novel concept...

> +
> +	/* if interrupt supported in the touch controller
> +	   timer polling need to stop */
> +	tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
> +	return IRQ_HANDLED;
> +}
> +
> +
> +static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> +	struct cy8ctmg110 *ts;
> +	struct input_dev *input_dev;
> +	int err;
> +	client->irq = CY8CTMG110_TOUCH_IRQ;
> +
> +	if (!i2c_check_functionality(client->adapter,
> +					I2C_FUNC_SMBUS_READ_WORD_DATA))
> +		return -EIO;
> +
> +	ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
> +	input_dev = input_allocate_device();
> +
> +	if (!ts || !input_dev) {
> +		err = -ENOMEM;
> +		goto err_free_mem;
> +	}
> +
> +	ts->client = client;
> +	i2c_set_clientdata(client, ts);
> +
> +	ts->input = input_dev;
> +	ts->pending = false;
> +	ts->sleepmode = false;
> +
> +	snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
> +						dev_name(&client->dev));
> +
> +	input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
> +	input_dev->phys = ts->phys;
> +	input_dev->id.bustype = BUS_I2C;
> +
> +	spin_lock_init(&ts->lock);
> +
> +	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |

You usually do not set up autorepeat for pointingt devices.

> +					BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);

The device does not emit relative events.

> +	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> +
> +	input_set_capability(input_dev, EV_KEY, KEY_F);

KEY_F?

> +
> +	input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
> +	input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
> +
> +	err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
> +
> +	if (err) {
> +		dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
> +						CY8CTMG110_RESET_PIN_GPIO);
> +		goto err_free_irq;
> +	}
> +	cy8ctmg110_power(true);
> +
> +	ts->initController = false;
> +	ts->i2c_fail_count = 0;
> +
> +	hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> +	ts->timer.function = cy8ctmg110_timer;
> +
> +	if (polling)
> +		hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
> +

Polling mode shoudl be controlled by platform data, not kernel module I think.

> +	/* Can we fall back to polling if these bits fail - something to look
> +	   at for robustness */
> +
> +	err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
> +	if (err < 0) {
> +		dev_err(&client->dev,
> +			"cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
> +						CY8CTMG110_IRQ_PIN_GPIO, err);
> +		goto err_free_timer;
> +	}
> +
> +	err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
> +
> +	if (err < 0) {
> +		dev_err(&client->dev,
> +			"cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
> +						CY8CTMG110_IRQ_PIN_GPIO, err);
> +		goto err_free_gpio;
> +	}
> +	client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
> +
> +	if (client->irq < 0) {
> +		err = client->irq;
> +		dev_err(&client->dev,
> +	"cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
> +						CY8CTMG110_IRQ_PIN_GPIO, err);
> +		goto err_free_gpio;
> +	}
> +	err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
> +	if (err < 0) {
> +		dev_err(&client->dev,
> +			"cy8ctmg110 irq %d busy? error %d\n",
> +				client->irq, err);
> +		goto err_free_gpio;
> +	}
> +
> +	err = input_register_device(input_dev);
> +	if (!err)
> +		return 0;
> +err_free_gpio:
> +	gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
> +err_free_timer:
> +	if (polling)
> +		hrtimer_cancel(&ts->timer);
> +err_free_irq:
> +	free_irq(client->irq, ts);
> +err_free_mem:
> +	input_free_device(input_dev);
> +	kfree(ts);
> +	return err;
> +}
> +
> +/*
> + * cy8ctmg110_suspend
> + * 
> + */
> +
> +static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
> +{

Stop timer here? Also power down the device?

> +	if (device_may_wakeup(&client->dev))
> +		enable_irq_wake(client->irq);
> +
> +	return 0;
> +}
> +
> +/*
> + * cy8ctmg110_resume 
> + * 
> + */
> +
> +static int cy8ctmg110_resume(struct i2c_client *client)
> +{
> +	if (device_may_wakeup(&client->dev))
> +		disable_irq_wake(client->irq);
> +
> +	return 0;
> +}
> +
> +/*
> + * cy8ctmg110_remove
> + * 
> + */
> +
> +static int cy8ctmg110_remove(struct i2c_client *client)
> +{
> +	struct cy8ctmg110 *ts = i2c_get_clientdata(client);
> +
> +	cy8ctmg110_power(false);
> +
> +	if (polling)
> +		hrtimer_cancel(&ts->timer);

Implement close() method and move the code above there? Also do open().

> +	free_irq(client->irq, ts);
> +	input_unregister_device(ts->input);
> +	/* FIXME: Do we need to free the GPIO ? */
> +	kfree(ts);
> +	return 0;
> +}
> +
> +static struct i2c_device_id cy8ctmg110_idtable[] = {
> +	{CY8CTMG110_DRIVER_NAME, 1},
> +	{}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
> +
> +static struct i2c_driver cy8ctmg110_driver = {
> +	.driver = {
> +		   .owner = THIS_MODULE,
> +		   .name = CY8CTMG110_DRIVER_NAME,
> +		   .bus = &i2c_bus_type,
> +		   },
> +	.id_table = cy8ctmg110_idtable,
> +	.probe = cy8ctmg110_probe,
> +	.remove = cy8ctmg110_remove,
> +	.suspend = cy8ctmg110_suspend,
> +	.resume = cy8ctmg110_resume,
> +};
> +
> +static int __init cy8ctmg110_init(void)
> +{
> +	return i2c_add_driver(&cy8ctmg110_driver);
> +}
> +
> +static void __exit cy8ctmg110_exit(void)
> +{
> +	i2c_del_driver(&cy8ctmg110_driver);
> +}
> +
> +module_init(cy8ctmg110_init);
> +module_exit(cy8ctmg110_exit);
> +
> +MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
> +MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
> +MODULE_LICENSE("GPL v2");
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Dmitry

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rafi Rubin <rafi@seas.upenn.edu>
Subject: Re: your mail
Date: Thu, 15 Apr 2010 19:41:22 -0400
Message-ID: <4BC7A422.7050601@seas.upenn.edu>
References: <20100414125234.23507.42816.stgit@localhost.localdomain> <20100414231604.GA12281@core.coreip.homeip.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <linux-input-owner@vger.kernel.org>
In-Reply-To: <20100414231604.GA12281@core.coreip.homeip.net>
Sender: linux-input-owner@vger.kernel.org
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>, linux-i2c@vger.kernel.org, khali@linux-fr.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
List-Id: linux-i2c@vger.kernel.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> +	if (ts->tc.event_sended == false) {
> 
> We set "event_sended" to false immediately before calling
> cy8ctmg110_send_event() so I do not see the point of this flag.

On that note:

$ git grep -n sended
drivers/net/eth16i.c:1295:
		how many packets there is to be sended */
drivers/net/wan/sbni.c:638:
		/* if frame was sended but not ACK'ed - resend it */
drivers/net/wan/sbni.c:659:
		* frame sended then in prepare_to_send next frame
drivers/usb/serial/aircable.c:13:
		* next two bytes must say how much data will be sended.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvHpB4ACgkQwuRiAT9o609wAgCfbGjTP2lIN6JJyX28VzjPHxTY
ylIAn15FZRPpBEkWaFR8oAFKCCRmNF4d
=u4nx
-----END PGP SIGNATURE-----

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: your mail
Date: Thu, 15 Apr 2010 21:21:04 -0700
Message-ID: <20100416042104.GA20916@core.coreip.homeip.net>
References: <20100414125234.23507.42816.stgit@localhost.localdomain>
 <20100414231604.GA12281@core.coreip.homeip.net>
 <4BC7A422.7050601@seas.upenn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-input-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <4BC7A422.7050601@seas.upenn.edu>
Sender: linux-input-owner@vger.kernel.org
To: Rafi Rubin <rafi@seas.upenn.edu>
Cc: Alan Cox <alan@linux.intel.com>, linux-i2c@vger.kernel.org, khali@linux-fr.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
List-Id: linux-i2c@vger.kernel.org

On Thu, Apr 15, 2010 at 07:41:22PM -0400, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >> +	if (ts->tc.event_sended == false) {
> > 
> > We set "event_sended" to false immediately before calling
> > cy8ctmg110_send_event() so I do not see the point of this flag.
> 
> On that note:
> 
> $ git grep -n sended
> drivers/net/eth16i.c:1295:
> 		how many packets there is to be sended */
> drivers/net/wan/sbni.c:638:
> 		/* if frame was sended but not ACK'ed - resend it */
> drivers/net/wan/sbni.c:659:
> 		* frame sended then in prepare_to_send next frame
> drivers/usb/serial/aircable.c:13:
> 		* next two bytes must say how much data will be sended.
> 

Well, if you want to go down that path...

[dtor@hammer work]$ grep -r -e "\(setted\|setuped\|split\+ed\)" . | wc -l
54
[dtor@hammer work]$ 

-- 
Dmitry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=fuDz=QM=vger.kernel.org=linux-integrity-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 8561BC282CB
	for <linux-integrity@archiver.kernel.org>; Tue,  5 Feb 2019 09:27:37 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 5CCEE2080F
	for <linux-integrity@archiver.kernel.org>; Tue,  5 Feb 2019 09:27:37 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1727501AbfBEJ1h (ORCPT
        <rfc822;linux-integrity@archiver.kernel.org>);
        Tue, 5 Feb 2019 04:27:37 -0500
Received: from mga09.intel.com ([134.134.136.24]:57498 "EHLO mga09.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725898AbfBEJ1h (ORCPT <rfc822;linux-integrity@vger.kernel.org>);
        Tue, 5 Feb 2019 04:27:37 -0500
X-Amp-Result: UNSCANNABLE
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
  by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2019 01:27:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.56,562,1539673200"; 
   d="scan'208";a="131640006"
Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.172])
  by orsmga002.jf.intel.com with ESMTP; 05 Feb 2019 01:27:34 -0800
Date:   Tue, 5 Feb 2019 11:27:32 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Matthew Garrett <matthewgarrett@google.com>
Cc:     linux-integrity@vger.kernel.org, peterhuewe@gmx.de, jgg@ziepe.ca,
        roberto.sassu@huawei.com
Subject: Re: your mail
Message-ID: <20190205092732.GC7427@linux.intel.com>
References: <20190204213303.131064-1-matthewgarrett@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190204213303.131064-1-matthewgarrett@google.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-integrity-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-integrity.vger.kernel.org>
X-Mailing-List: linux-integrity@vger.kernel.org

On Mon, Feb 04, 2019 at 01:32:59PM -0800, Matthew Garrett wrote:
> V2: Rebased on top of Roberto's patches, no other changes. Tested on an
> Intel NUC using PTT-based TPM2, binary_bios_measurements contains boot
> events.

Thank you. Looking forward to review this. I'll land Roberto's patches
and then this would be next in the queue.

/Jarkko

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Henrik Rydberg" <rydberg@euromail.se>
Subject: Re: your mail
Date: Wed, 25 Jan 2012 14:26:12 +0100
Message-ID: <20120125132612.GA3890@polaris.bitmath.org>
References: <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-input-owner@vger.kernel.org>
Received: from smtprelay-b12.telenor.se ([62.127.194.21]:38629 "EHLO
	smtprelay-b12.telenor.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752511Ab2AYN0S (ORCPT
	<rfc822;linux-input@vger.kernel.org>);
	Wed, 25 Jan 2012 08:26:18 -0500
Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166])
	by smtprelay-b12.telenor.se (Postfix) with ESMTP id 6A600EB89A
	for <linux-input@vger.kernel.org>; Wed, 25 Jan 2012 14:26:15 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>
Sender: linux-input-owner@vger.kernel.org
List-Id: linux-input@vger.kernel.org
To: mcuelenaere@gmail.com
Cc: linux-input@vger.kernel.org

Hi Maurus,

> Subject: [RFC] HID: add Microsoft Touch Mouse driver
> 
> This patch adds support for the proprietary Microsoft Touch Mouse
> multitouch protocol.

Exciting stuff, nice job on the patch too. Please find some initial
comments inline.

> @@ -0,0 +1,371 @@
> +/*
> + *  HID driver for the Microsoft Touch Mouse
> + *
> + *  Copyright (c) 2011 Maurus Cuelenaere <mcuelenaere@gmail.com>
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
> +
> +#include "hid-ids.h"
> +
> +#define MSTM_RAW_DATA_HID_ID		0x27
> +#define MSTM_RAW_DATA_FOOTER		0x51
> +
> +#define MSTM_DATA_WIDTH			15
> +#define MSTM_DATA_HEIGHT		13
> +
> +struct mstm_raw_data_packet {
> +	__u8 hid_id;
> +	__u8 data_length;
> +	__u16 unk1;
> +	__u8 unk2;
> +	__u8 footer;
> +	__u8 timestamp;
> +	__u8 data[25]; /* milliseconds */
> +};

I take it this means you get at most 50 nibbles per transfer?

> +
> +struct mstm_state {
> +	bool advance_flag;
> +	int x;
> +	int y;
> +	unsigned char last_timestamp;
> +	unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
> +};

The ability to simply send an "input screen" would be perfect
here. This device may be on the border of what can/should be handled
via input events. A memory mapped driver, uio-based or something
similar, could be an option.

> +
> +struct mstm_device {
> +	struct input_dev *input;
> +
> +	struct mstm_state state;
> +};
> +
> +#define MSTM_INTERFACE_KEYBOARD		0
> +#define MSTM_INTERFACE_MOUSE		1
> +#define MSTM_INTERFACE_CONTROL		2
> +
> +static inline int hid_get_interface_number(struct hid_device *hdev) {
> +	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> +	return intf->cur_altsetting->desc.bInterfaceNumber;
> +}
> +
> +/*
> + * The mouse sensor only yields data for a specific part of its surface.
> + * Because of this, we can't just increase x and y uniformly; so there's
> + * a need for this simple algorithm.
> + *
> + * Visual representation of available data:
> + *    0 1 2 3 4 5 6 7 8 9 A B C D E F
> + *  0       * * * * * * * * * *
> + *  1     * * * * * * * * * * * *
> + *  2   * * * * * * * * * * * * * *
> + *  3   * * * * * * * * * * * * * *
> + *  4 * * * * * * * * * * * * * * * *
> + *  5 * * * * * * * * * * * * * * * *
> + *  6 * * * * * * * * * * * * * * * *
> + *  7 * * * * * * * * * * * * * * * *
> + *  8 * * * * * * * * * * * * * * * *
> + *  9 * * * * * * * * * * * * * * * *
> + *  A * * * * * * * * * * * * * * * *
> + *  B * * * * * * * * * * * * * * * *
> + *  C * * * * * * * * * * * * * * * *
> + *  D * * * * * * * * * * * * * * * *
> + */
> +static void mstm_advance_pointer(struct mstm_state *state)
> +{
> +	int max, nextMin;
> +
> +	state->x++;
> +
> +	switch (state->y) {
> +	case 0:
> +		max = 11;
> +		nextMin = 2;
> +		break;
> +	case 1:
> +		max = 12;
> +		nextMin = 1;
> +		break;
> +	case 2:
> +		max = 13;
> +		nextMin = 1;
> +		break;
> +	case 3:
> +		max = 13;
> +		nextMin = 0;
> +		break;
> +	default:
> +		max = 14;
> +		nextMin = 0;
> +		break;
> +	}
> +
> +	if (state->x > max) {
> +		state->y++;
> +		state->x = nextMin;
> +	}
> +}
> +
> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
> +{
> +	int i;
> +
> +	if (state->advance_flag) {
> +		state->advance_flag = false;
> +		for (i = -3; i < nibble; i++)
> +			mstm_advance_pointer(state);
> +	} else {
> +		if (nibble == 0xF) {
> +			/* The next nibble will indicate how many
> +			* positions to advance, so set a flag */
> +			state->advance_flag = true;
> +		} else {
> +			state->data[state->x][state->y] = nibble;
> +			mstm_advance_pointer(state);
> +		}
> +	}
> +}

Looking good.

> +static void mstm_push_data(struct hid_device *hdev)
> +{
> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> +	struct input_dev *input = mstm_dev->input;
> +	int x, y;
> +
> +	for (x = 0; x < MSTM_DATA_WIDTH; x++) {
> +		for (y = 0; y < MSTM_DATA_HEIGHT; y++) {
> +			unsigned char pressure = mstm_dev->state.data[x][y];
> +			if (pressure > 0) {
> +				//input_report_abs(input, ABS_MT_BLOB_ID, 1);
> +				//input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
> +				input_report_abs(input, ABS_MT_POSITION_X, x);
> +				input_report_abs(input, ABS_MT_POSITION_Y, y);
> +				input_mt_sync(input);
> +			}
> +		}
> +	}

True, the blob id has not yet been used, but its definition is
different from how it is used here. Also, since you do not attempt any
kind of clustering (single-linkage or similar), the blob as stated
might not even be connected. One possible option could be to use the
slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
else. The device would (rightfully) not be recognized as MT since the
position is missing, all data would be available for processing in
userspace, and bandwidth would be minimized since there could only be
so many changes coming in per millisecond.

> +static int mstm_input_mapping(struct hid_device *hdev,
> +		struct hid_input *hi, struct hid_field *field,
> +		struct hid_usage *usage, unsigned long **bit, int *max)
> +{
> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> +
> +	//printk("mstm_input_mapping(%p)\n", hdev);
> +
> +	/* bail early if not the correct interface */
> +	if (mstm_dev == NULL)
> +		return 0;
> +
> +	/* HACK: get rid of ABS_MT_* params */
> +	if ((usage->hid & HID_USAGE_PAGE) == HID_UP_GENDESK)
> +		return -1;

I am not sure about the hack here, nor its explanation. ;-)

> +
> +	/* map input device to hid device */
> +	mstm_dev->input = hi->input;
> +
> +	return 0;
> +}
> +
> +static void mstm_setup_input(struct mstm_device *mstm)
> +{
> +	__set_bit(EV_ABS, mstm->input->evbit);
> +
> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
> +
> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
> +
> +	input_set_events_per_packet(mstm->input, 60);
> +}

Regarding the resolution of touch major, it is generally assumed (in
userspace) that the units are the same as the position, so scaling in
the driver is reasonable. Otherwise, why not specify resolution for
touch major as well?

Thanks,
Henrik

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maurus Cuelenaere <mcuelenaere@gmail.com>
Subject: Re: your mail
Date: Wed, 25 Jan 2012 15:09:24 +0100
Message-ID: <4F200D14.80702@gmail.com>
References: <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se> <20120125132612.GA3890@polaris.bitmath.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <linux-input-owner@vger.kernel.org>
Received: from mail-we0-f174.google.com ([74.125.82.174]:48857 "EHLO
	mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751313Ab2AYOJ1 (ORCPT
	<rfc822;linux-input@vger.kernel.org>);
	Wed, 25 Jan 2012 09:09:27 -0500
Received: by werb13 with SMTP id b13so3813995wer.19
        for <linux-input@vger.kernel.org>; Wed, 25 Jan 2012 06:09:26 -0800 (PST)
In-Reply-To: <20120125132612.GA3890@polaris.bitmath.org>
Sender: linux-input-owner@vger.kernel.org
List-Id: linux-input@vger.kernel.org
To: Henrik Rydberg <rydberg@euromail.se>
Cc: linux-input@vger.kernel.org

Hi Henrik,

Op 25-01-12 14:26, Henrik Rydberg schreef:
> Hi Maurus,
>
>> Subject: [RFC] HID: add Microsoft Touch Mouse driver
>>
>> This patch adds support for the proprietary Microsoft Touch Mouse
>> multitouch protocol.
> Exciting stuff, nice job on the patch too. Please find some initial
> comments inline.
>
>> @@ -0,0 +1,371 @@
>> +/*
>> + *  HID driver for the Microsoft Touch Mouse
>> + *
>> + *  Copyright (c) 2011 Maurus Cuelenaere<mcuelenaere@gmail.com>
>> + *
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> + *
>> + */
>> +
>> +#include<linux/device.h>
>> +#include<linux/input.h>
>> +#include<linux/hid.h>
>> +#include<linux/module.h>
>> +#include<linux/usb.h>
>> +
>> +#include "hid-ids.h"
>> +
>> +#define MSTM_RAW_DATA_HID_ID		0x27
>> +#define MSTM_RAW_DATA_FOOTER		0x51
>> +
>> +#define MSTM_DATA_WIDTH			15
>> +#define MSTM_DATA_HEIGHT		13
>> +
>> +struct mstm_raw_data_packet {
>> +	__u8 hid_id;
>> +	__u8 data_length;
>> +	__u16 unk1;
>> +	__u8 unk2;
>> +	__u8 footer;
>> +	__u8 timestamp;
>> +	__u8 data[25]; /* milliseconds */
>> +};
> I take it this means you get at most 50 nibbles per transfer?

Correct.

Hmm, looks like that milliseconds comment needs to be on the line above it.

>> +
>> +struct mstm_state {
>> +	bool advance_flag;
>> +	int x;
>> +	int y;
>> +	unsigned char last_timestamp;
>> +	unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
>> +};
> The ability to simply send an "input screen" would be perfect
> here. This device may be on the border of what can/should be handled
> via input events. A memory mapped driver, uio-based or something
> similar, could be an option.

In my first tests, I was doing readouts in userspace using hidraw, which 
performed quite well.

Bandwidth could be an issue, but I'd like to use the current APIs as 
much as possible so I don't need to go modifying mtdev, X, ...

>> +
>> +struct mstm_device {
>> +	struct input_dev *input;
>> +
>> +	struct mstm_state state;
>> +};
>> +
>> +#define MSTM_INTERFACE_KEYBOARD		0
>> +#define MSTM_INTERFACE_MOUSE		1
>> +#define MSTM_INTERFACE_CONTROL		2
>> +
>> +static inline int hid_get_interface_number(struct hid_device *hdev) {
>> +	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>> +	return intf->cur_altsetting->desc.bInterfaceNumber;
>> +}
>> +
>> +/*
>> + * The mouse sensor only yields data for a specific part of its surface.
>> + * Because of this, we can't just increase x and y uniformly; so there's
>> + * a need for this simple algorithm.
>> + *
>> + * Visual representation of available data:
>> + *    0 1 2 3 4 5 6 7 8 9 A B C D E F
>> + *  0       * * * * * * * * * *
>> + *  1     * * * * * * * * * * * *
>> + *  2   * * * * * * * * * * * * * *
>> + *  3   * * * * * * * * * * * * * *
>> + *  4 * * * * * * * * * * * * * * * *
>> + *  5 * * * * * * * * * * * * * * * *
>> + *  6 * * * * * * * * * * * * * * * *
>> + *  7 * * * * * * * * * * * * * * * *
>> + *  8 * * * * * * * * * * * * * * * *
>> + *  9 * * * * * * * * * * * * * * * *
>> + *  A * * * * * * * * * * * * * * * *
>> + *  B * * * * * * * * * * * * * * * *
>> + *  C * * * * * * * * * * * * * * * *
>> + *  D * * * * * * * * * * * * * * * *
>> + */
>> +static void mstm_advance_pointer(struct mstm_state *state)
>> +{
>> +	int max, nextMin;
>> +
>> +	state->x++;
>> +
>> +	switch (state->y) {
>> +	case 0:
>> +		max = 11;
>> +		nextMin = 2;
>> +		break;
>> +	case 1:
>> +		max = 12;
>> +		nextMin = 1;
>> +		break;
>> +	case 2:
>> +		max = 13;
>> +		nextMin = 1;
>> +		break;
>> +	case 3:
>> +		max = 13;
>> +		nextMin = 0;
>> +		break;
>> +	default:
>> +		max = 14;
>> +		nextMin = 0;
>> +		break;
>> +	}
>> +
>> +	if (state->x>  max) {
>> +		state->y++;
>> +		state->x = nextMin;
>> +	}
>> +}
>> +
>> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
>> +{
>> +	int i;
>> +
>> +	if (state->advance_flag) {
>> +		state->advance_flag = false;
>> +		for (i = -3; i<  nibble; i++)
>> +			mstm_advance_pointer(state);
>> +	} else {
>> +		if (nibble == 0xF) {
>> +			/* The next nibble will indicate how many
>> +			* positions to advance, so set a flag */
>> +			state->advance_flag = true;
>> +		} else {
>> +			state->data[state->x][state->y] = nibble;
>> +			mstm_advance_pointer(state);
>> +		}
>> +	}
>> +}
> Looking good.
>
>> +static void mstm_push_data(struct hid_device *hdev)
>> +{
>> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> +	struct input_dev *input = mstm_dev->input;
>> +	int x, y;
>> +
>> +	for (x = 0; x<  MSTM_DATA_WIDTH; x++) {
>> +		for (y = 0; y<  MSTM_DATA_HEIGHT; y++) {
>> +			unsigned char pressure = mstm_dev->state.data[x][y];
>> +			if (pressure>  0) {
>> +				//input_report_abs(input, ABS_MT_BLOB_ID, 1);
>> +				//input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
>> +				input_report_abs(input, ABS_MT_POSITION_X, x);
>> +				input_report_abs(input, ABS_MT_POSITION_Y, y);
>> +				input_mt_sync(input);
>> +			}
>> +		}
>> +	}
> True, the blob id has not yet been used, but its definition is
> different from how it is used here. Also, since you do not attempt any
> kind of clustering (single-linkage or similar), the blob as stated
> might not even be connected.

Indeed, without clustering the BLOB_ID would be useless but that line 
was only for testing with one finger.

> One possible option could be to use the
> slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
> else. The device would (rightfully) not be recognized as MT since the
> position is missing, all data would be available for processing in
> userspace, and bandwidth would be minimized since there could only be
> so many changes coming in per millisecond.

So how does userspace then finds out where these pressure points are 
located?
Or do you mean to just dump all data to user space (15 * 13 * 
sizeof(ABS_MT_PRESSURE value) + overhead)?

>> +static int mstm_input_mapping(struct hid_device *hdev,
>> +		struct hid_input *hi, struct hid_field *field,
>> +		struct hid_usage *usage, unsigned long **bit, int *max)
>> +{
>> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> +
>> +	//printk("mstm_input_mapping(%p)\n", hdev);
>> +
>> +	/* bail early if not the correct interface */
>> +	if (mstm_dev == NULL)
>> +		return 0;
>> +
>> +	/* HACK: get rid of ABS_MT_* params */
>> +	if ((usage->hid&  HID_USAGE_PAGE) == HID_UP_GENDESK)
>> +		return -1;
> I am not sure about the hack here, nor its explanation. ;-)

The HID tables specify some ABS_MT_* values and I didn't know whether 
these were going to conflict with the ones I report above, so I just 
discard all GenericDesktop fields.

root@hp4530s:~# grep MT /sys/kernel/debug/hid/0003\:045E\:0773.0006/rdesc
GenericDesktop.MultiAxis ---> Absolute.MTMajor
GenericDesktop.0009 ---> Absolute.MTMinor
GenericDesktop.000a ---> Absolute.MTMajorW
GenericDesktop.000b ---> Absolute.MTMinorW
GenericDesktop.000c ---> Absolute.MTOrientation
GenericDesktop.000d ---> Absolute.MTPositionX
GenericDesktop.000e ---> Absolute.MTPositionY
GenericDesktop.000f ---> Absolute.MTToolType
GenericDesktop.0010 ---> Absolute.MTBlobID

>> +
>> +	/* map input device to hid device */
>> +	mstm_dev->input = hi->input;
>> +
>> +	return 0;
>> +}
>> +
>> +static void mstm_setup_input(struct mstm_device *mstm)
>> +{
>> +	__set_bit(EV_ABS, mstm->input->evbit);
>> +
>> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
>> +
>> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
>> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
>> +
>> +	input_set_events_per_packet(mstm->input, 60);
>> +}
> Regarding the resolution of touch major, it is generally assumed (in
> userspace) that the units are the same as the position, so scaling in
> the driver is reasonable. Otherwise, why not specify resolution for
> touch major as well?

I didn't specify it because other HID drivers only specified resolutions 
for POSITION_{X,Y}, I'll try it and see how mtview reacts.

Thanks for the review!

-- 
Maurus Cuelenaere


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Subject: Re: your mail
Date: Mon, 24 Feb 2014 17:28:50 +0000
Message-ID: <20140224172850.GG2553@mudshark.cambridge.arm.com>
References: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: srikanth TS <srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
List-Id: iommu@lists.linux-foundation.org

On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> Hi Will Deacon,

Hello,

> Currently SMMU driver expecting all stream ID used by respective master
> should be defined in the DT.
> 
> We want to know how to handle in the case of virtual functions dynamically
> created and destroyed.
> 
> Is PCI driver responsible for creating stream ID respective BDand
> requesting SMMU to add to the mapping table[stream Id to context mapping
> table]?
> 
> Or is there any right way of doing it?

Correct, the driver currently doesn't support dynamic mappings (mainly
because I didn't want to try and invent something that I couldn't test).

There are a couple of ways to solve this:

  (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
      within a fixed range. That would probably need some code in the bus
      layer, so that a bus notifier can kick and call back to the relevant
      SMMU.

  (2) Describe the RID -> SID mapping in the device-tree. We probably want
      to avoid an enormous table, so this would only work for simple `SID =
      RID + offset' or 'SID = RID & mask' cases.

How do your IDs map to each other?

Will

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Subject: RE: your mail
Date: Tue, 25 Feb 2014 11:28:49 +0000
Message-ID: <42a1041ac2df4a73a94dc4516969e35d@BL2PR03MB468.namprd03.prod.outlook.com>
References: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>
	<20140224172850.GG2553@mudshark.cambridge.arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
In-Reply-To: <20140224172850.GG2553-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
Content-Language: en-US
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, srikanth TS <srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
List-Id: iommu@lists.linux-foundation.org



> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> Sent: Monday, February 24, 2014 10:59 PM
> To: srikanth TS
> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> Subject: Re: your mail
> 
> On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > Hi Will Deacon,
> 
> Hello,
> 
> > Currently SMMU driver expecting all stream ID used by respective
> > master should be defined in the DT.
> >
> > We want to know how to handle in the case of virtual functions
> > dynamically created and destroyed.
> >
> > Is PCI driver responsible for creating stream ID respective BDand
> > requesting SMMU to add to the mapping table[stream Id to context
> > mapping table]?
> >
> > Or is there any right way of doing it?
> 
> Correct, the driver currently doesn't support dynamic mappings (mainly
> because I didn't want to try and invent something that I couldn't test).
> 
> There are a couple of ways to solve this:
> 
>   (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
>       within a fixed range. That would probably need some code in the bus
>       layer, so that a bus notifier can kick and call back to the
> relevant
>       SMMU.
This could be done in add device notifier. I am working on similar(not PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC patch by next week.

-Varun

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Subject: Re: your mail
Date: Tue, 25 Feb 2014 15:01:25 +0000
Message-ID: <20140225150125.GC23136@mudshark.cambridge.arm.com>
References: <CAM0G4ztXWM5kw6dV4WRrTVJBMmeJDXuRnbeRBE603hM+7c=PCg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <CAM0G4ztXWM5kw6dV4WRrTVJBMmeJDXuRnbeRBE603hM+7c=PCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: srikanth TS <srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
List-Id: iommu@lists.linux-foundation.org

On Tue, Feb 25, 2014 at 11:20:11AM +0000, srikanth TS wrote:
> 
> On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org<mailto:will.deacon-5wv7dgnIgG8@public.gmane.org>> wrote:
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective master
> > > should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions dynamically
> > > created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context mapping
> > > table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> >   (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> >       within a fixed range. That would probably need some code in the bus
> >       layer, so that a bus notifier can kick and call back to the relevant
> >       SMMU.
> 
> I think first way of solving seems to be better, because we don't know how many
> 
> VF are used and i feel its not good idea to keep whole list of streamID [which is
> 
> equal to max num vf] in DT. Again in this method we need to generate the stream ID
> 
> dynamically whenever VF is added in pci iov driver side. And then pass that
> 
> stream ID to SMMU.
> 
> Is it ok this way?  Or you prefer 2nd way which is simpler.

I'm happy either way, but I'd need to see some patches before I can merge
anything ;)

Will

From mboxrd@z Thu Jan  1 00:00:00 1970
From: srikanth TS <srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: RE: your mail
Date: Wed, 26 Feb 2014 17:23:19 +0900
Message-ID: <CAM0G4zv7nBLRdiXcFjiarXAhsbA+5MkdWHPysjpn=ydky72Piw@mail.gmail.com>
References: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>
	<20140224172850.GG2553@mudshark.cambridge.arm.com>
	<42a1041ac2df4a73a94dc4516969e35d@BL2PR03MB468.namprd03.prod.outlook.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3118327616030262043=="
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
In-Reply-To: <42a1041ac2df4a73a94dc4516969e35d-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
List-Id: iommu@lists.linux-foundation.org

--===============3118327616030262043==
Content-Type: multipart/alternative; boundary=089e015365e6d77ed704f34aea17

--089e015365e6d77ed704f34aea17
Content-Type: text/plain; charset=ISO-8859-1

On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> > Subject: Re: your mail
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective
> > > master should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions
> > > dynamically created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context
> > > mapping table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> >   (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an
SMMU
> >       within a fixed range. That would probably need some code in the
bus
> >       layer, so that a bus notifier can kick and call back to the
> > relevant
> >       SMMU.
> This could be done in add device notifier. I am working on similar(not
PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC
patch by next week.
Can you please explain with little more detail. We just want to make sure
your idea fits in for pci iov also.

-Srikanth ts
>
> -Varun
>

--089e015365e6d77ed704f34aea17
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Feb 25, 2014 8:28 PM, &quot;Varun Sethi&quot; &lt;<a href=3D"mailto:Varu=
n.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org">Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: <a href=3D"mailto:iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"=
>iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org</a> [mailto:<a href=3D"mailto:iom=
mu-">iommu-</a><br>
&gt; &gt; <a href=3D"mailto:bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org">bounces@lis=
ts.linux-foundation.org</a>] On Behalf Of Will Deacon<br>
&gt; &gt; Sent: Monday, February 24, 2014 10:59 PM<br>
&gt; &gt; To: srikanth TS<br>
&gt; &gt; Cc: <a href=3D"mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org">iommu@lis=
ts.linux-foundation.org</a>; <a href=3D"mailto:sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org">=
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org</a>; linux-<br>
&gt; &gt; <a href=3D"mailto:kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org">kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<=
/a>; <a href=3D"mailto:ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org">ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org</a>=
<br>
&gt; &gt; Subject: Re: your mail<br>
&gt; &gt;<br>
&gt; &gt; On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:<br>
&gt; &gt; &gt; Hi Will Deacon,<br>
&gt; &gt;<br>
&gt; &gt; Hello,<br>
&gt; &gt;<br>
&gt; &gt; &gt; Currently SMMU driver expecting all stream ID used by respec=
tive<br>
&gt; &gt; &gt; master should be defined in the DT.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We want to know how to handle in the case of virtual functio=
ns<br>
&gt; &gt; &gt; dynamically created and destroyed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Is PCI driver responsible for creating stream ID respective =
BDand<br>
&gt; &gt; &gt; requesting SMMU to add to the mapping table[stream Id to con=
text<br>
&gt; &gt; &gt; mapping table]?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Or is there any right way of doing it?<br>
&gt; &gt;<br>
&gt; &gt; Correct, the driver currently doesn&#39;t support dynamic mapping=
s (mainly<br>
&gt; &gt; because I didn&#39;t want to try and invent something that I coul=
dn&#39;t test).<br>
&gt; &gt;<br>
&gt; &gt; There are a couple of ways to solve this:<br>
&gt; &gt;<br>
&gt; &gt; =A0 (1) Add a way for a PCI RC to dynamically allocate StreamIDs =
on an SMMU<br>
&gt; &gt; =A0 =A0 =A0 within a fixed range. That would probably need some c=
ode in the bus<br>
&gt; &gt; =A0 =A0 =A0 layer, so that a bus notifier can kick and call back =
to the<br>
&gt; &gt; relevant<br>
&gt; &gt; =A0 =A0 =A0 SMMU.<br>
&gt; This could be done in add device notifier. I am working on similar(not=
 PCI) hot plug device infrastructure for arm smmu driver. I will post an RF=
C patch by next week.<br>
Can you please explain with little more detail. We just want to make sure y=
our idea fits in for pci iov also.</p>
<p dir=3D"ltr">-Srikanth ts<br>
&gt;<br>
&gt; -Varun<br>
&gt;<br>
</p>

--089e015365e6d77ed704f34aea17--

--===============3118327616030262043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============3118327616030262043==--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Subject: RE: your mail
Date: Wed, 26 Feb 2014 12:14:38 +0000
Message-ID: <74d3514e1ab74eb5ab0234596745fb50@BL2PR03MB468.namprd03.prod.outlook.com>
References: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>
	<20140224172850.GG2553@mudshark.cambridge.arm.com>
	<42a1041ac2df4a73a94dc4516969e35d@BL2PR03MB468.namprd03.prod.outlook.com>
	<CAM0G4zv7nBLRdiXcFjiarXAhsbA+5MkdWHPysjpn=ydky72Piw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1231349967331023674=="
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
In-Reply-To: <CAM0G4zv7nBLRdiXcFjiarXAhsbA+5MkdWHPysjpn=ydky72Piw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-Language: en-US
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: srikanth TS <srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" <ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
List-Id: iommu@lists.linux-foundation.org

--===============1231349967331023674==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_"

--_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: srikanth TS [mailto:srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, February 26, 2014 1:53 PM
To: Sethi Varun-B16395
Cc: sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Will Deacon; =
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: RE: your mail


On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org<mailto:Va=
run.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:iommu-bounces@lis=
ts.linux-foundation.org> [mailto:iommu-<mailto:iommu->
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:bounces-cunTk1MwBs9QetFLy7KEm967fi48ZQAG@public.gmane.org=
n.org>] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:iommu-cunTk1MwBs9QetFLy7KEm967fi48ZQAG@public.gmane.org=
n.org>; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org<mailto:sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>; linu=
x-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<mailto:kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; ts.srikanth@sams=
ung.com<mailto:ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> > Subject: Re: your mail
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective
> > > master should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions
> > > dynamically created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context
> > > mapping table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test)=
.
> >
> > There are a couple of ways to solve this:
> >
> >   (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SM=
MU
> >       within a fixed range. That would probably need some code in the b=
us
> >       layer, so that a bus notifier can kick and call back to the
> > relevant
> >       SMMU.
> This could be done in add device notifier. I am working on similar(not PC=
I) hot plug device infrastructure for arm smmu driver. I will post an RFC p=
atch by next week.
Can you please explain with little more detail. We just want to make sure y=
our idea fits in for pci iov also.

[Sethi Varun-B16395] In the add device notifier we can allocate the streamI=
D (and the corresponding smmu master), while allocating the iommu group for=
 the PCI devices. All, the PCIe devices sharing the same iommu group would =
share the stream ID.  Currently, I am working on a add device framework for=
 hot plug devices.

-Varun

--_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> srikanth=
 TS [mailto:srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
<br>
<b>Sent:</b> Wednesday, February 26, 2014 1:53 PM<br>
<b>To:</b> Sethi Varun-B16395<br>
<b>Cc:</b> sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Will D=
eacon; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org<br>
<b>Subject:</b> RE: your mail<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p><br>
On Feb 25, 2014 8:28 PM, &quot;Varun Sethi&quot; &lt;<a href=3D"mailto:Varu=
n.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org">Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: <a href=3D"mailto:iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"=
>iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org</a> [mailto:<a href=3D"mailto:iom=
mu-">iommu-</a><br>
&gt; &gt; <a href=3D"mailto:bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org">bounces@lis=
ts.linux-foundation.org</a>] On Behalf Of Will Deacon<br>
&gt; &gt; Sent: Monday, February 24, 2014 10:59 PM<br>
&gt; &gt; To: srikanth TS<br>
&gt; &gt; Cc: <a href=3D"mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org">iommu@lis=
ts.linux-foundation.org</a>;
<a href=3D"mailto:sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org">sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org</a=
>; linux-<br>
&gt; &gt; <a href=3D"mailto:kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org">kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<=
/a>; <a href=3D"mailto:ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org">
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org</a><br>
&gt; &gt; Subject: Re: your mail<br>
&gt; &gt;<br>
&gt; &gt; On Mon, Feb 24, 2014 at 03:12:21PM &#43;0000, srikanth TS wrote:<=
br>
&gt; &gt; &gt; Hi Will Deacon,<br>
&gt; &gt;<br>
&gt; &gt; Hello,<br>
&gt; &gt;<br>
&gt; &gt; &gt; Currently SMMU driver expecting all stream ID used by respec=
tive<br>
&gt; &gt; &gt; master should be defined in the DT.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We want to know how to handle in the case of virtual functio=
ns<br>
&gt; &gt; &gt; dynamically created and destroyed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Is PCI driver responsible for creating stream ID respective =
BDand<br>
&gt; &gt; &gt; requesting SMMU to add to the mapping table[stream Id to con=
text<br>
&gt; &gt; &gt; mapping table]?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Or is there any right way of doing it?<br>
&gt; &gt;<br>
&gt; &gt; Correct, the driver currently doesn't support dynamic mappings (m=
ainly<br>
&gt; &gt; because I didn't want to try and invent something that I couldn't=
 test).<br>
&gt; &gt;<br>
&gt; &gt; There are a couple of ways to solve this:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; (1) Add a way for a PCI RC to dynamically allocate StreamI=
Ds on an SMMU<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; within a fixed range. That would probably ne=
ed some code in the bus<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; layer, so that a bus notifier can kick and c=
all back to the<br>
&gt; &gt; relevant<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; SMMU.<br>
&gt; This could be done in add device notifier. I am working on similar(not=
 PCI) hot plug device infrastructure for arm smmu driver. I will post an RF=
C patch by next week.<br>
Can you please explain with little more detail. We just want to make sure y=
our idea fits in for pci iov also.<o:p></o:p></p>
<p><b><i><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">[Sethi Varun-B16395]
</span></i></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;;color:#1F497D">In the add device notifier we can=
 allocate the streamID (and the corresponding smmu master), while allocatin=
g the iommu group for the PCI devices. All, the PCIe devices
 sharing the same iommu group would share the stream ID. &nbsp;Currently, I=
 am working on a add device framework for hot plug devices.<o:p></o:p></spa=
n></p>
<p><b><i><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">-Varun</span></i></b><span style=3D"fon=
t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=
#1F497D"><o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_--

--===============1231349967331023674==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============1231349967331023674==--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>
Subject: Re: your mail
Date: Fri, 31 Aug 2018 13:23:49 -0700
Message-ID: <20180831202349.xcz45jjcy7xvx3yk@pburton-laptop>
References: <20180827145032.9522-1-hch@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <20180827145032.9522-1-hch-jcswGhMUV9g@public.gmane.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/iommu/>
List-Post: <mailto:iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/iommu>,
	<mailto:iommu-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
List-Id: iommu@lists.linux-foundation.org

Hi Christoph,

On Mon, Aug 27, 2018 at 04:50:27PM +0200, Christoph Hellwig wrote:
> Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
> 
> While most architectures are either always or never dma coherent for a
> given build, the arm, arm64, mips and soon arc architectures can have
> different dma coherent settings on a per-device basis.  Additionally
> some mips builds can decide at boot time if dma is coherent or not.
> 
> I've started to look into handling noncoherent dma in swiotlb, and
> moving the dma-iommu ops into common code [1], and for that we need a
> generic way to check if a given device is coherent or not.  Moving
> this flag into struct device also simplifies the conditionally coherent
> architecture implementations.
> 
> These patches are also available in a git tree given that they have
> a few previous posted dependencies:
> 
>     git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
> 
> Gitweb:
> 
>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge

Apart from the nits in patch 2, these look sane to me from a MIPS
perspective, so for patches 1-4:

    Acked-by: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org> # MIPS parts

Thanks,
    Paul

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Paillard <simon.paillard-RGJHTEmuthQGuQl/6FzYuenJ6Cvpl5oe@public.gmane.org>
Subject: Re: your mail
Date: Tue, 3 Jul 2012 22:19:30 +0200
Message-ID: <20120703201930.GB15283@glenfiddich.mraw.org>
References: <4FF3539B.50103@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <4FF3539B.50103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Elie De Brauwer <eliedebrauwer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
List-Id: linux-man@vger.kernel.org

On Tue, Jul 03, 2012 at 10:18:35PM +0200, Elie De Brauwer wrote:
> subscribe linux-man

Not to the list, to majordomo itself:
http://vger.kernel.org/majordomo-info.html#subscription

-- 
Simon Paillard
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61E797E110
	for <linux-man@vger.kernel.org>; Thu, 25 Dec 2025 13:48:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1766670496; cv=none; b=qHdmLRVeyytGOT+3+YhfoL54y1K3g3dzYi1SzsDC3WKRC6zGvt2ojsyvNZC/09EFxQnb5o4XAAjXlPrRDLLss08gNiGNQi71DjPLObM5QYYRuqMlevGRId0MR4u53ds0S/+VQzUGDpZKpElmTeAcCyfXjJWC21g26F4wFFa7aOk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1766670496; c=relaxed/simple;
	bh=WXrOsoXV71x09N0acgNXrzFnyPKfI7Bb0correTRAgw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Dh/WoFeF8MNWU18BdTrf4YzeLd20ftPbUQX6J7BpapGB9GREOwX59VpY4ZBABS/qHziCX6fnfJ3iJ6qUu8g0Rbq5f7KypoYyrLywfFblfwJ4j05MyX0c1TyYptO+lYjKaawtleDw818gvE6Kze8qpZRoJgKRRPkNhz+vFZnQ/c8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Iw+WHeot; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Iw+WHeot"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CD58C4CEF1;
	Thu, 25 Dec 2025 13:48:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1766670495;
	bh=WXrOsoXV71x09N0acgNXrzFnyPKfI7Bb0correTRAgw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Iw+WHeotgUrCaBl+BhB8opUJ5Gmp3N9MDkcVBC20GBhBQ+vS4dWMtkQMwswYALr9Z
	 GXho9w27GwuVELcLtFDuFcO8DW3dKjC7kgWgi4FwddM++rlx8wfmlsh9L7kO/9F1wd
	 /wXZRWJsQ/NYpf+wZYK6+GI/LjUS5mD2qmAL8+UcUw8lI06lDAcolxA4TzgmjqcdtM
	 +wwKvj+s0v6lhU4qirLgUgmvUQTl95shqgS8N9dI9tXpY3RoP35So1uG7as0ndqBTF
	 0QM+YpV5vl1TxdKnbtKnWe2S0QNd8zNFQ2iBlAe28D2HkgNKVo7aO9/n23lfje76o6
	 C9ejdb/ebmOHg==
Date: Thu, 25 Dec 2025 14:48:13 +0100
From: Alejandro Colomar <alx@kernel.org>
To: Helge Kreutzmann <debian@helgefjell.de>
Cc: mario.blaettermann@gmail.com, linux-man@vger.kernel.org
Subject: Re: your mail
Message-ID: <aU1AVrV5umYVs7CT@devuan>
References: <aUv635HpEQKac8rI@meinfjell.helgefjelltest.de>
Precedence: bulk
X-Mailing-List: linux-man@vger.kernel.org
List-Id: <linux-man.vger.kernel.org>
List-Subscribe: <mailto:linux-man+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-man+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="col7edbh3luevrmj"
Content-Disposition: inline
In-Reply-To: <aUv635HpEQKac8rI@meinfjell.helgefjelltest.de>


--col7edbh3luevrmj
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <alx@kernel.org>
To: Helge Kreutzmann <debian@helgefjell.de>
Cc: mario.blaettermann@gmail.com, linux-man@vger.kernel.org
Subject: Re: your mail
Message-ID: <aU1AVrV5umYVs7CT@devuan>
References: <aUv635HpEQKac8rI@meinfjell.helgefjelltest.de>
MIME-Version: 1.0
In-Reply-To: <aUv635HpEQKac8rI@meinfjell.helgefjelltest.de>

Hi Helge,

On Wed, Dec 24, 2025 at 02:38:23PM +0000, Helge Kreutzmann wrote:
> Without further ado, the following was found:
>=20
> Man page: console_codes.4
> Issue:    Why hard word wraps?

This looks like an issue in the software that produces the files you're
reading.  The hard word wraps are not present in the source code, and
the manual page reads just fine when formatted.


Cheers,
Alex

>=20
> "Set palette, with parameter given in 7 hexadecimal digits\n"
> "I<nrrggbb>\n"
> "after the final P.\n"
> "Here\n"
> "I<n>\n"
> "is the color (0\\[en]15),\n"
> "and\n"
> "I<rrggbb>\n"
> "indicates\n"
> "the red/green/blue values (0\\[en]255)."
>=20
> "Set screen blank timeout to\n"
> "I<n>\n"
> "minutes."
>=20
> "Set icon name and window title to\n"
> "I<txt>."
>=20
> #. type: tbl table
> #: archlinux debian-unstable mageia-cauldron opensuse-tumbleweed
> #, no-wrap
> "Change log file to\n"
> "I<name>\n"
> "(normally disabled by a compile-time option)."
>=20
> "Cursor to lower left corner of screen (if enabled\n"
> "by\n"
> "B<xterm>(1)'s\n"
> "B<hpLowerleftBugCompat>\n"
> "resource)."

--=20
<https://www.alejandro-colomar.es>

--col7edbh3luevrmj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmlNQJwACgkQ64mZXMKQ
wqnHjw/+IptgKetrxQRxvT6DEIswltiEDJdcEjhMrG3JGzsBEmYaS3NDrsZaHC5W
qBR/bFtsQOCx0MI0Y/bJaSayZXk/QvQ06lU4jgI5d8Plv1BLj3KRxL5UyqEdT52L
woC2oHP2teYUXbzav29AjDimbLPA1Cvw4FGLQROQeViL49eqcLhfgeQs8G8OYNeX
v+XopQUTYhhfm9MURLM+iOSQKwJgVTCDTSeXnxEVhoscJnMAjIQZ9oq4SVNdJMIj
NfkO2gYuVWSSeuR0TJccKQ0yxEdiNOTk2L1pdgu+z4yTvNiRXdSkEICX7dEhMd8b
4SFp7DFjVEZE9IqINp26cDD3JBInqRFCHimOtJd3xcGo+OKYMJ/VhNy9KAMvWgv8
1t8sbWWfZQvNptrdny6QNdnNLx7LPUpNHvSxvDWxIkcVX9N0/kMkmdZa/64/v7va
r41uingwjH1KC+STvFqR9UOiQJQ8o0wseo6BuOrLZ3X9lPFbxTfmGOuGjcWE4NVq
RHPF1fuZcM1VaDxqt0vmXdt1FZBeDusb56avQck7praSMbSe2qTrun9DfssYkl6Z
JyVutLbWWtRHXwJWxuGJdwFbNfN4NVSBaWx+frFZgz7Xa22qVyZMpT3xnaams4qm
lf3W/WYwjFB4895Q6KjrbzyKnTU+5MhxjPKrjzK4j0HU7bEZFk0=
=pgap
-----END PGP SIGNATURE-----

--col7edbh3luevrmj--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail.helgefjell.de (mail.helgefjell.de [142.132.201.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8ED91459FA
	for <linux-man@vger.kernel.org>; Fri, 26 Dec 2025 04:59:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=142.132.201.35
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1766725186; cv=none; b=dVJDhMqBDzdjS0lwr2JfdAJxBRtWeD7RVuwDQ00W3/GnXSer/xgnHKAf3HXvj8KjT/Ao1vRNSUggF07h27iaw9At7CRcsbB3ZjQMlhOroCmpKKpp5q2dPzilWvdcRA1P5zEXVbYn7R1zpwH6HxKcZNDTPrJ6CNa5UKxkmSMZ/CU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1766725186; c=relaxed/simple;
	bh=SejqiZb0G98wPy5bloPHLpu0PPU7BqsMRwLQAsnOPt0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Mz1pRrSiFtxnY7V9QKN+r9Bo3JM5MwxbTLDIadqr8033tBbLMt4TKV/bPUXaUIL/GvqWlvPA4YLql6ZRjdNhrJSEHo6y5LlxZ/h5k1CAOf44IjuBvu4FB6QjDaLsBVOR21/SAZH071G/gManx/iJjxbMiAdS0wxIEGDrKucAaP8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=helgefjell.de; spf=pass smtp.mailfrom=helgefjell.de; dkim=pass (2048-bit key) header.d=helgefjell.de header.i=@helgefjell.de header.b=l5+qnINA; arc=none smtp.client-ip=142.132.201.35
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=helgefjell.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=helgefjell.de
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=helgefjell.de header.i=@helgefjell.de header.b="l5+qnINA"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helgefjell.de;
	s=selector.helgefjell; t=1766725182;
	bh=//Ip1eCGOx0WoZ3B1pPtIpLCenhSUc5wObQ2dp6ZWws=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=l5+qnINARy1sWcBUaCMjgnRzzb7dyI23mpetcmJKLhIiyEgCibLr1OnXAFe2K6xUK
	 aRn3CbkZvHthqTgZ8H5hFH6eIsZsmRnm4RAD77bH7dwRsComeAKWH2lPsap3raxcW9
	 QWNj5S2aL5b4AudmWEk2gF8+gC8KkgIRWeQ6bLJrxA4GcTuZbB2yQAjvXOxlpFDPQ+
	 ytohtGn+jjMCjcU2y8nz8pxvTzerRrtli8MKwUA6PaSnWlUETRW+QD0QneSol8j8yQ
	 IH8jibef2jgAp/2WfE2lK7wsccL2sx4SvCOn5qZ24ejo5VGNye7j4cNq5aj0Gx6K7q
	 RjAoESthGqWlA==
Original-Subject: Re: your mail
Author: Helge Kreutzmann <debian@helgefjell.de>
Original-Cc: mario.blaettermann@gmail.com, linux-man@vger.kernel.org
Received: from localhost (localhost [127.0.0.1])
  (uid 1002)
  by mail.helgefjell.de with local
  id 00000000000200D3.00000000694E163E.00024556; Fri, 26 Dec 2025 04:59:42 +0000
Date: Fri, 26 Dec 2025 04:59:42 +0000
From: Helge Kreutzmann <debian@helgefjell.de>
To: Alejandro Colomar <alx@kernel.org>
Cc: mario.blaettermann@gmail.com, linux-man@vger.kernel.org
Subject: Re: your mail
Message-ID: <aU4WPvRscIvTrzfS@meinfjell.helgefjelltest.de>
References: <aUv635HpEQKac8rI@meinfjell.helgefjelltest.de>
 <aU1AVrV5umYVs7CT@devuan>
Precedence: bulk
X-Mailing-List: linux-man@vger.kernel.org
List-Id: <linux-man.vger.kernel.org>
List-Subscribe: <mailto:linux-man+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-man+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=_meinfjell-148822-1766725182-0001-2"
Content-Disposition: inline
In-Reply-To: <aU1AVrV5umYVs7CT@devuan>
X-Public-Key-URL: http://www.helgefjell.de/data/debian_neu.asc
X-homepage: http://www.helgefjell.de/debian

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_meinfjell-148822-1766725182-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Alex,
Am Thu, Dec 25, 2025 at 02:48:13PM +0100 schrieb Alejandro Colomar:
> On Wed, Dec 24, 2025 at 02:38:23PM +0000, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> >=20
> > Man page: console_codes.4
> > Issue:    Why hard word wraps?
>=20
> This looks like an issue in the software that produces the files you're
> reading.  The hard word wraps are not present in the source code, and
> the manual page reads just fine when formatted.

Thanks. This would be po4a. I reported similar issues in the past,
however, po4a has not yet handled these reports[1].

Once this bugs is resolved, I can revisit if this has also resolved
this issue.

Greetings

        Helge

[1] https://bugs.debian.org/1115900

--=20
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

--=_meinfjell-148822-1766725182-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEbZZfteMW0gNUynuwQbqlJmgq5nAFAmlOFj4ACgkQQbqlJmgq
5nANAw//dNqnxGXfaca8w3xhCL5B83tiRmpwLTArpnQXMtf/5G6RoZBqUah6JuaC
0iSNhRNzLoE17o3JemobsZgdd103H5sTqh4m9DfFjTA87HyxgGtdco35kelqaco6
XMPrL4oSVkbLpuloFPuXBDfIU3Oock44P2pL9pF06B+5uBhHo5jhsUpdVIjZCVIa
oMGAV5GDJnmuXSL6Twp3pKNrsK7onErJ8xwhee6ms+6VGr8X6aW88UEeQMkWbLPP
v/vOwX1pZdVYY3Q/ae5SI85u5ybX/K04hTxJ1fHAek+dKFoKcg+EC2P1nkw9FdJy
p26Gq89QBkjN5BerHJwSjC3xSSa+5PwqMnqNg0RoRldq5QQDLdOf1aUSSHO+STd6
jlAUHNTF50DBXHoBhfbX0l3Jw/0SMghI3x1DzHTfWtMxaUzBg4s++z8gS8zkzUBj
jBYaD2uzNd5eSZNPebI6gdVYBGOGabyQzdLzZYNgLnfiI0/PmCpYtQ3NpgSDiJef
KmJpC51juJE7rC0B5PQI9jlAYeqcfTbaLG6yZYQgZOTXIBa7cNQhaEvOT/37bOeL
TVIBB54WNL0nVjyYqCdcLV+6hm/LpKfr5A4CU8l152O9mC1qlmoKYooYw1uQNX8j
gRwYPM+e21WhzEermWMY9sKxj1CC/tW6FJj039ZAE8N4XTnfJE0=
=l2r1
-----END PGP SIGNATURE-----

--=_meinfjell-148822-1766725182-0001-2--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id KAA138237; Sat, 9 Aug 1997 10:42:18 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA18660 for linux-list; Sat, 9 Aug 1997 10:41:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA18651 for <linux@cthulhu.engr.sgi.com>; Sat, 9 Aug 1997 10:41:53 -0700
Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA23174
	for <linux@cthulhu.engr.sgi.com>; Sat, 9 Aug 1997 10:41:50 -0700
	env-from (ralf@informatik.uni-koblenz.de)
Received: from thoma (ralf@thoma.uni-koblenz.de [141.26.4.61]) by informatik.uni-koblenz.de (8.8.6/8.6.9) with SMTP id TAA09294; Sat, 9 Aug 1997 19:41:41 +0200 (MEST)
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-Id: <199708091741.TAA09294@informatik.uni-koblenz.de>
Received: by thoma (SMI-8.6/KO-2.0)
	id TAA16668; Sat, 9 Aug 1997 19:41:40 +0200
Subject: Re: your mail
To: vincent@waw.com (Vincent Renardias)
Date: Sat, 9 Aug 1997 19:41:39 +0200 (MET DST)
Cc: linux@cthulhu.engr.sgi.com
In-Reply-To: <Pine.LNX.3.95.970809175116.19882B-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 06:16:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id LAA138177; Sat, 9 Aug 1997 11:36:47 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA29157 for linux-list; Sat, 9 Aug 1997 11:36:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA29140 for <linux@engr.sgi.com>; Sat, 9 Aug 1997 11:36:27 -0700
Received: from odin.waw.com (ns1.waw.com [194.51.88.250]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id LAA00622
	for <linux@engr.sgi.com>; Sat, 9 Aug 1997 11:36:25 -0700
	env-from (vincent@waw.com)
Received: from odin.waw.com (vincent@mail.waw.com [194.51.88.252]) by odin.waw.com (8.7.3/8.7.3/waw) with SMTP id UAA27158; Sat, 9 Aug 1997 20:40:06 +0100
Date: Sat, 9 Aug 1997 20:40:06 +0100 (GMT+0100)
From: Vincent Renardias <vincent@waw.com>
To: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
cc: linux@cthulhu.engr.sgi.com
Subject: Re: your mail
In-Reply-To: <199708091741.TAA09294@informatik.uni-koblenz.de>
Message-ID: <Pine.LNX.3.95.970809195755.24185B-100000@odin.waw.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk


On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > 2/ While using the crossdev gcc, several times I got complains about a
> > file 'sgidefs.h' missing (from
> > /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> > Commenting the '#include' file made the compile work, but I not sure it's
> > the right fix. 
> 
> Not the right thing, but won't hurt.  I shows that your libc is
> not installed correctly.

I just installed the binutils/gcc crossdev packages from
ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
(i386).

[Thanx for the explanation on endianess ;]

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id MAA141214; Sat, 9 Aug 1997 12:43:13 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09219 for linux-list; Sat, 9 Aug 1997 12:42:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09208 for <linux@engr.sgi.com>; Sat, 9 Aug 1997 12:42:51 -0700
Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA08922
	for <linux@engr.sgi.com>; Sat, 9 Aug 1997 12:42:49 -0700
	env-from (ralf@informatik.uni-koblenz.de)
Received: from thoma (ralf@thoma.uni-koblenz.de [141.26.4.61]) by informatik.uni-koblenz.de (8.8.6/8.6.9) with SMTP id VAA22164; Sat, 9 Aug 1997 21:42:40 +0200 (MEST)
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-Id: <199708091942.VAA22164@informatik.uni-koblenz.de>
Received: by thoma (SMI-8.6/KO-2.0)
	id VAA16786; Sat, 9 Aug 1997 21:42:39 +0200
Subject: Re: your mail
To: vincent@waw.com (Vincent Renardias)
Date: Sat, 9 Aug 1997 21:42:38 +0200 (MET DST)
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
In-Reply-To: <Pine.LNX.3.95.970809195755.24185B-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 08:40:06 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id NAA141844; Sat, 9 Aug 1997 13:01:52 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13069 for linux-list; Sat, 9 Aug 1997 13:01:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA13062 for <linux@engr.sgi.com>; Sat, 9 Aug 1997 13:01:30 -0700
Received: from odin.waw.com (ns1.waw.com [194.51.88.250]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id NAA10954
	for <linux@engr.sgi.com>; Sat, 9 Aug 1997 13:01:27 -0700
	env-from (vincent@waw.com)
Received: from odin.waw.com (vincent@mail.waw.com [194.51.88.252]) by odin.waw.com (8.7.3/8.7.3/waw) with SMTP id WAA29835; Sat, 9 Aug 1997 22:05:02 +0100
Date: Sat, 9 Aug 1997 22:05:02 +0100 (GMT+0100)
From: Vincent Renardias <vincent@waw.com>
To: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
cc: linux@cthulhu.engr.sgi.com
Subject: Re: your mail
In-Reply-To: <199708091942.VAA22164@informatik.uni-koblenz.de>
Message-ID: <Pine.LNX.3.95.970809214814.29239A-100000@odin.waw.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk


On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > I just installed the binutils/gcc crossdev packages from
> > ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> > from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> > (i386).
> 
> Well, it doesn't matter except that I built the executables with Linux
> libc and you therefore need that one.  DANGER:  When you install libs
> for a crosscompiler you will have to move the libs a bit around.
> Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
> just has too much octane to be suitable as fuel for your Intel machine ;-)

Debian provides nice tools to handdle this kind of installation:

- alien: allows to convert binary packages between any 2 of the
{.deb,.tgz,.rpm} formats.

- dpkg-cross: tool handdling cross-compilation packages. That is any file
that should go into /*/lib is redirected into /usr/local/$ARCH-linux/lib.
(same for the include files). It also makes it possible to build a given
package for several architectures at the same time.
Those tools should probably work on any Linux flavour (distrib./arch.)

Anyway, I've installed glibc-2.0.4 to get around the missing sgidefs.h
problem, and I run into another problem:
now mips-linux-gcc complains about:

% mips-linux-gcc  -o pwgen pwgen.o -lm
/usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
index; run ranlib to add one

running mips-linux-ranlib on the given file does not change anything.
(ie: still getting the same message)

Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id OAA143578; Sat, 9 Aug 1997 14:12:36 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA25977 for linux-list; Sat, 9 Aug 1997 14:12:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA25967 for <linux@engr.sgi.com>; Sat, 9 Aug 1997 14:12:14 -0700
Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA19624
	for <linux@engr.sgi.com>; Sat, 9 Aug 1997 14:12:12 -0700
	env-from (ralf@informatik.uni-koblenz.de)
Received: from thoma (ralf@thoma.uni-koblenz.de [141.26.4.61]) by informatik.uni-koblenz.de (8.8.6/8.6.9) with SMTP id XAA01472; Sat, 9 Aug 1997 23:12:01 +0200 (MEST)
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-Id: <199708092112.XAA01472@informatik.uni-koblenz.de>
Received: by thoma (SMI-8.6/KO-2.0)
	id XAA16857; Sat, 9 Aug 1997 23:11:57 +0200
Subject: Re: your mail
To: vincent@waw.com (Vincent Renardias)
Date: Sat, 9 Aug 1997 23:11:56 +0200 (MET DST)
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
In-Reply-To: <Pine.LNX.3.95.970809214814.29239A-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 10:05:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id PAA146389; Sat, 9 Aug 1997 15:59:23 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08414 for linux-list; Sat, 9 Aug 1997 15:58:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA08398 for <linux@cthulhu.engr.sgi.com>; Sat, 9 Aug 1997 15:58:44 -0700
Received: from neon.ingenia.ca (neon.ingenia.ca [205.207.220.57]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id PAA02591
	for <linux@cthulhu.engr.sgi.com>; Sat, 9 Aug 1997 15:58:43 -0700
	env-from (shaver@neon.ingenia.ca)
Received: (from shaver@localhost) by neon.ingenia.ca (8.8.5/8.7.3) id SAA17511; Sat, 9 Aug 1997 18:53:58 -0400
From: Mike Shaver <shaver@neon.ingenia.ca>
Message-Id: <199708092253.SAA17511@neon.ingenia.ca>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.3.95.970809214814.29239A-100000@odin.waw.com> from Vincent Renardias at "Aug 9, 97 10:05:02 pm"
To: vincent@waw.com (Vincent Renardias)
Date: Sat, 9 Aug 1997 18:53:58 -0400 (EDT)
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by neteng.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) via SMTP id SAA150788; Sat, 9 Aug 1997 18:53:53 -0700 (PDT)
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
Received: (from majordomo@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA00021 for linux-list; Sat, 9 Aug 1997 18:53:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA29994 for <linux@engr.sgi.com>; Sat, 9 Aug 1997 18:53:32 -0700
Received: from odin.waw.com (ns1.waw.com [194.51.88.250]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id SAA22270
	for <linux@engr.sgi.com>; Sat, 9 Aug 1997 18:53:30 -0700
	env-from (vincent@waw.com)
Received: from odin.waw.com (vincent@mail.waw.com [194.51.88.252]) by odin.waw.com (8.7.3/8.7.3/waw) with SMTP id DAA08014; Sun, 10 Aug 1997 03:57:06 +0100
Date: Sun, 10 Aug 1997 03:57:06 +0100 (GMT+0100)
From: Vincent Renardias <vincent@waw.com>
Reply-To: Vincent Renardias <vincent@waw.com>
To: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
cc: linux@cthulhu.engr.sgi.com
Subject: Re: your mail
In-Reply-To: <199708092112.XAA01472@informatik.uni-koblenz.de>
Message-ID: <Pine.LNX.3.95.970810033007.7033A-100000@odin.waw.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux@cthulhu.engr.sgi.com
Precedence: bulk


On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > % mips-linux-gcc  -o pwgen pwgen.o -lm
> > /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> > index; run ranlib to add one
> > 
> > running mips-linux-ranlib on the given file does not change anything.
> > (ie: still getting the same message)
> > 
> > Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
> 
> No.  Looks as if your lib still isn't correctly installed.  If ranlib
> doesn't help, then your libc.a is probably corrupted into a zero lenght
> file.

You're right. (Not an empty file through, but somehow it got truncated to
~50 K). Reinstalling fixed it.

Here's the list of what I compiled so far:

file_3.20.1-6_mips.deb              gzip_1.2.4-15_mips.deb
debmake_3.3.11_mips.deb             grep_2.0-12_mips.deb
dpkg-dev_1.4.0.8_all.deb            makedev_1.6-16_mips.deb
dpkg_1.4.0.8_mips.deb               sysklogd_1.3-17_mips.deb
dpkg_1.4.0.8_mips.nondebbin.tar.gz  update_1.3-1_mips.deb
cpio_2.4.2-11_mips.deb              tar_1.12-1_mips.deb
patch_2.2-1_mips.deb                sed_2.05-15_mips.deb
flex_2.5.4a-1_mips.deb              findutils_4.1-23_mips.deb
bison_1.25-9_mips.deb               shellutils_1.16-4_mips.deb
diff_2.7-13_mips.deb                textutils_1.22-2_mips.deb
rpm_2.4.2-2_mips.deb                pwgen_1-8_mips.deb
adduser_3.6_all.deb

These packages are available from odin.waw.com/pub/linux (the pgp signed
checksums are in the changes/ subdirectory). I'd be glad if someone could
test a few of them and tell me if everything is okay.

Quick install instructions:
untar the file dpkg_1.4.0.8_mips.nondebbin.tar.gz at the root of your FS,
then install other packages with 'dpkg -i foo.deb'.

	Cordialement,

-- 
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553668AbRADPqN>;
	Thu, 4 Jan 2001 07:46:13 -0800
Received: from brutus.conectiva.com.br ([200.250.58.146]:53497 "EHLO
        dhcp046.distro.conectiva") by oss.sgi.com with ESMTP
	id <S553660AbRADPp4>; Thu, 4 Jan 2001 07:45:56 -0800
Received: (ralf@lappi) by bacchus.dhis.org id <S868134AbRADPg3>;
	Thu, 4 Jan 2001 13:36:29 -0200
Date:	Thu, 4 Jan 2001 13:36:29 -0200
From:	Ralf Baechle <ralf@oss.sgi.com>
To:	John Van Horne <JohnVan.Horne@cosinecom.com>
Cc:	"'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
Message-ID: <20010104133629.C936@bacchus.dhis.org>
References: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com>; from JohnVan.Horne@cosinecom.com on Wed, Jan 03, 2001 at 05:36:44PM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote:

> First, while the kernel builds just fine, when we use objcopy to convert the
> elf image into a binary
> image which we can download to our target, objcopy fails with warnings
> saying that it is writing
> sections to huge (i.e. negative) file offsets. When I use objdump to analyze
> the kernel image,
> I see that our start address of 0x80102584 has been turned into
> 0xffffffff80102584. I'm thinking that
> I need to tell ld something to stop it from doing this. Any ideas?

That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
Older binutils used to zero-extend addresses which was broken.  So what
you observe is actually the sympthom of a bug that got fixed.

> Second, the way we build our application, we first create a partially linked
> image, with the -r flag. Then 
> we run ld on this (and an additional object file). When we do this with the
> tools from cross-all-001027
> we get the following error on the second link step:
> 
> mips-linux-ld:  BFD internal error, aborting at
> /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c
> line 6942 in _bfd_mips_elf_relocate_section
> 
> mips-linux-ld: Please report this bug.

Not good ...  Two possibilities.

 - it's fairly easy to make ld die in funny ways by feeding it with nonsense
   options, linker scripts or similar.
 - it's really a bug.

Assuming it's really a bug, can you extract a small test case that
demonstrate this bug?

> Actually, on the application we didn't get this far using
> binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
> so I have nothing to compare it to.  I'm not sure if this is a bug or if I
> should be passing some flags to gcc or ld.

It may well be a bug; especially -r is used relativly rarely so the code
isn't getting excercised too well.  I'd like to see it get fixed in the
current linker, though.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553733AbRADQ0n>;
	Thu, 4 Jan 2001 08:26:43 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:52141 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553661AbRADQ0U>;
	Thu, 4 Jan 2001 08:26:20 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA11844;
	Thu, 4 Jan 2001 17:22:52 +0100 (MET)
Date:   Thu, 4 Jan 2001 17:22:51 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@oss.sgi.com>
cc:     John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
In-Reply-To: <20010104133629.C936@bacchus.dhis.org>
Message-ID: <Pine.GSO.3.96.1010104171213.4624E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 4 Jan 2001, Ralf Baechle wrote:

> > I see that our start address of 0x80102584 has been turned into
> > 0xffffffff80102584. I'm thinking that
> > I need to tell ld something to stop it from doing this. Any ideas?
> 
> That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
> Older binutils used to zero-extend addresses which was broken.  So what
> you observe is actually the sympthom of a bug that got fixed.

 I'm not sure that's the best solution, I'm afraid.  For elf32-mips
addresses should be 32-bit and not 64-bit.  It would be consistent with
other 32-bit platforms, it would make interoperability easier (ksymoops
cannot make use of System.map to grok kernel oopses which provide 32-bit
addresses) and it would make objdump outputs more readable.

 Fixing this problem with BFD is on my to do list (but has a low priority
assigned). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553750AbRADQtn>;
	Thu, 4 Jan 2001 08:49:43 -0800
Received: from blackdog.wirespeed.com ([208.170.106.25]:1546 "EHLO
        blackdog.wirespeed.com") by oss.sgi.com with ESMTP
	id <S553661AbRADQtV>; Thu, 4 Jan 2001 08:49:21 -0800
Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4])
	by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id KAA09708;
	Thu, 4 Jan 2001 10:35:04 -0600
Message-ID: <3A54A789.1070608@redhat.com>
Date:   Thu, 04 Jan 2001 10:40:41 -0600
From:   Joe deBlaquiere <jadb@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     Ralf Baechle <ralf@oss.sgi.com>,
        John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
References: <Pine.GSO.3.96.1010104171213.4624E-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

If the BFD stuff is built with any support for 64 bit (even as an 
optional target) it will maintain all addresses as 64-bit values, even 
if the file is 32 bit.

There is a bug in that "some" newer versions of objcopy will not allow 
you to translate these sign-extended 32 bit addresses into Intel Hex 
format.

If you're really only doing 32-bit mips you might consider removing the 
64 bit targets in the config.bfd... I think that will solve the problems.

Maciej W. Rozycki wrote:

> On Thu, 4 Jan 2001, Ralf Baechle wrote:
> 
> 
>>> I see that our start address of 0x80102584 has been turned into
>>> 0xffffffff80102584. I'm thinking that
>>> I need to tell ld something to stop it from doing this. Any ideas?
>> 
>> That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
>> Older binutils used to zero-extend addresses which was broken.  So what
>> you observe is actually the sympthom of a bug that got fixed.
> 
> 
>  I'm not sure that's the best solution, I'm afraid.  For elf32-mips
> addresses should be 32-bit and not 64-bit.  It would be consistent with
> other 32-bit platforms, it would make interoperability easier (ksymoops
> cannot make use of System.map to grok kernel oopses which provide 32-bit
> addresses) and it would make objdump outputs more readable.
> 
>  Fixing this problem with BFD is on my to do list (but has a low priority
> assigned). 

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553780AbRADRWx>;
	Thu, 4 Jan 2001 09:22:53 -0800
Received: from brutus.conectiva.com.br ([200.250.58.146]:2043 "EHLO
        dhcp046.distro.conectiva") by oss.sgi.com with ESMTP
	id <S553661AbRADRWm>; Thu, 4 Jan 2001 09:22:42 -0800
Received: (ralf@lappi) by bacchus.dhis.org id <S868136AbRADRNm>;
	Thu, 4 Jan 2001 15:13:42 -0200
Date:	Thu, 4 Jan 2001 15:13:34 -0200
From:	Ralf Baechle <ralf@oss.sgi.com>
To:	Joe deBlaquiere <jadb@redhat.com>
Cc:	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
Message-ID: <20010104151334.C2525@bacchus.dhis.org>
References: <Pine.GSO.3.96.1010104171213.4624E-100000@delta.ds2.pg.gda.pl> <3A54A789.1070608@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3A54A789.1070608@redhat.com>; from jadb@redhat.com on Thu, Jan 04, 2001 at 10:40:41AM -0600
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:

> There is a bug in that "some" newer versions of objcopy will not allow 
> you to translate these sign-extended 32 bit addresses into Intel Hex 
> format.

I couldn't care less ...

> If you're really only doing 32-bit mips you might consider removing the 
> 64 bit targets in the config.bfd... I think that will solve the problems.

Doesn't really solve the problem.  For example on an Origin we have a 32-bit
userland but 64-bit kernel addresses which confuses ksymops and procps.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553864AbRADRcX>;
	Thu, 4 Jan 2001 09:32:23 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32430 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553692AbRADRcM>;
	Thu, 4 Jan 2001 09:32:12 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA13739;
	Thu, 4 Jan 2001 18:18:42 +0100 (MET)
Date:   Thu, 4 Jan 2001 18:18:41 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Joe deBlaquiere <jadb@redhat.com>
cc:     Ralf Baechle <ralf@oss.sgi.com>,
        John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
In-Reply-To: <3A54A789.1070608@redhat.com>
Message-ID: <Pine.GSO.3.96.1010104180809.4624G-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> If the BFD stuff is built with any support for 64 bit (even as an 
> optional target) it will maintain all addresses as 64-bit values, even 
> if the file is 32 bit.

 I do consider it fine BFD handles all addresses as 64-bit internally.  I
just think it should truncate them to 32-bits upon printing (and always
whenever appropriate) when the selected target is 32-bit.  It does so (it
has to!) for output anyway, so what's the deal? 

> If you're really only doing 32-bit mips you might consider removing the 
> 64 bit targets in the config.bfd... I think that will solve the problems.

 Nope, I insist 32-bit targets need to work correctly regardless of
whether there are any 64-bit ones supported by a particular BFD binary or
not.  Do you think elf32-i386 should switch to printing 64-bit addresses
if elf64-alpha is also supported by a given configuration of BFD?  I
don't.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553796AbRADRpY>;
	Thu, 4 Jan 2001 09:45:24 -0800
Received: from blackdog.wirespeed.com ([208.170.106.25]:41738 "EHLO
        blackdog.wirespeed.com") by oss.sgi.com with ESMTP
	id <S553768AbRADRpE>; Thu, 4 Jan 2001 09:45:04 -0800
Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4])
	by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id LAA11147;
	Thu, 4 Jan 2001 11:40:52 -0600
Message-ID: <3A54B6F4.7000909@redhat.com>
Date:   Thu, 04 Jan 2001 11:46:28 -0600
From:   Joe deBlaquiere <jadb@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     Ralf Baechle <ralf@oss.sgi.com>
CC:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
References: <Pine.GSO.3.96.1010104171213.4624E-100000@delta.ds2.pg.gda.pl> <3A54A789.1070608@redhat.com> <20010104151334.C2525@bacchus.dhis.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf Baechle wrote:

> On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:
> 
> If you're really only doing 32-bit mips you might consider removing the 
>> 64 bit targets in the config.bfd... I think that will solve the problems.
> 
> 
> Doesn't really solve the problem.  For example on an Origin we have a 32-bit
> userland but 64-bit kernel addresses which confuses ksymops and procps.
> 
>   Ralf


It was meant as a workaround...

Perhaps we could have an option to objcopy that would allow you to copy 
the addresses without sign extension?

Joe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553793AbRADSVZ>;
	Thu, 4 Jan 2001 10:21:25 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:25519 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553706AbRADSU7>;
	Thu, 4 Jan 2001 10:20:59 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA15729;
	Thu, 4 Jan 2001 19:12:21 +0100 (MET)
Date:   Thu, 4 Jan 2001 19:12:20 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Joe deBlaquiere <jadb@redhat.com>
cc:     Ralf Baechle <ralf@oss.sgi.com>,
        John Van Horne <JohnVan.Horne@cosinecom.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        "'wesolows@foobazco.org'" <wesolows@foobazco.org>
Subject: Re: your mail
In-Reply-To: <3A54B6F4.7000909@redhat.com>
Message-ID: <Pine.GSO.3.96.1010104190629.15475A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> It was meant as a workaround...
> 
> Perhaps we could have an option to objcopy that would allow you to copy 
> the addresses without sign extension?

 Please do either implement a clean solution or wait until someone else
(possibly me) does.  We don't want any more hacks -- MIPS/Linux already
has enough of them.  This is my view of the situation at present. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

From mboxrd@z Thu Jan  1 00:00:00 1970
Received:  by oss.sgi.com id <S553709AbRBOLFh>;
	Thu, 15 Feb 2001 03:05:37 -0800
Received: from mail.sonytel.be ([193.74.243.200]:49871 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553687AbRBOLFK>;
	Thu, 15 Feb 2001 03:05:10 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA03835;
	Thu, 15 Feb 2001 12:03:43 +0100 (MET)
Date:   Thu, 15 Feb 2001 12:03:43 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Deepa Suresh <deepa.suresh@WIPRO.COM>
cc:     linux-mips@oss.sgi.com
Subject: Re: your mail
In-Reply-To: <77452A3CA92.AAA7057@santa.mail.wipro.com>
Message-ID: <Pine.GSO.4.10.10102151201280.10238-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 14 Feb 2001, Deepa  Suresh wrote:
> We have a QED based MIPs processor, running Linux 2.4-test6. 
> We use our own graphics card.
> We want to get X/display up on this board. WE have a frame buffer driver
> written
> for the same card running on x86 Linux version and running X using
> XFBDev server.

Does the frame buffer driver you wrote for x86 Linux relies on the card being
initialised by the video BIOS on the card? If not, it'll work out-of-the-box.
If yes, you'll have to make sure a similar initialization is done on the MIPS
platform.

> I want to know if we can reuse the same driver for mips also?
> In the case of i386 Linux, fbcon.c and fbmem.c do most of the
> processing before giving control to the corresponding graphics card.
> 
> In mips port can we use the same fbcon.c and fbmem.c functionality 
> with our graphics driver. Is this enough for X to come up
> without any problems. (i have seen sgi using newport_con , can we use
> fb_con itself instead , what are the problems?)

Fbmem and fbcon should work fine. They are not architecture specific.

And if these work, XF{68,86}_FBDev should work as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f34LbqF00656
	for linux-mips-outgoing; Wed, 4 Apr 2001 14:37:52 -0700
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LbpM00653
	for <linux-mips@oss.sgi.com>; Wed, 4 Apr 2001 14:37:51 -0700
Received: from frednet.dyndns.org (user-33qt47m.dialup.mindspring.com [199.174.144.246])
	by barry.mail.mindspring.net (8.9.3/8.8.5) with SMTP id RAA05052
	for <linux-mips@oss.sgi.com>; Wed, 4 Apr 2001 17:37:48 -0400 (EDT)
Received: (qmail 22476 invoked by uid 1000); 4 Apr 2001 21:37:47 -0000
Date: Wed, 4 Apr 2001 16:37:47 -0500
From: Matthew Fredrickson <matt@frednet.dyndns.org>
To: jsc6233@ritvax.isc.rit.edu, linux-mips@oss.sgi.com
Subject: Re: your mail
Message-ID: <20010404163747.A22469@frednet.dyndns.org>
References: <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>; from jsc6233@ritvax.isc.rit.edu on Wed, Apr 04, 2001 at 05:29:54PM -0700
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 04, 2001 at 05:29:54PM -0700, jsc6233@ritvax.isc.rit.edu wrote:
>=20
> hello,
> Yeah i am trying to compile it while running Irix 6.5. Once i get it all=
=20
> working I was going to boot into it. Does that make sense?
> james

<g>No offense, but not really.  Actually, you'll probably need to start
off by setting up the x86-mips cross compilers on an x86 linux machine of
yours and booting the kernel via tftp over the network to get started.  I
think most of this is covered in the FAQ on the site.  Anyway, I don't
think it's _ever_ been supported to compile up the kernel in IRIX anyway,
so your kind of out of luck for that.  On a side note, you probably want
to stop by freeware.sgi.com and upgrade your gcc from 2.7 to the latest
(2.95.3 I think).  Might even try downloading some pre3.0 stuff and try
that out.  Back to topic:  Read EVERYTHING you can on the linux-mips sgi
site before asking a question here;  if you don't, that's a very good way
to get kindly (and a lot of times unkindly) pointed to the FAQ.  Hope this
helps.

--=20
Matthew Fredrickson AIM MatthewFredricks
ICQ 13923212 matt@NOSPAMfredricknet.net=20
http://www.fredricknet.net/~matt/
"Everything is relative"

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6y5QrHzCekITFKgsRAv8dAJ48BXa3ksHmb8khceS0s5jj4Tm4mQCfQ1KR
eKluaXCQYgFgqvZfvTzJ394=
=//D2
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f355C9J05563
	for linux-mips-outgoing; Wed, 4 Apr 2001 22:12:09 -0700
Received: from dea.waldorf-gmbh.de (u-109-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.109])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f355BjM05556
	for <linux-mips@oss.sgi.com>; Wed, 4 Apr 2001 22:11:58 -0700
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f3558VZ11841;
	Thu, 5 Apr 2001 07:08:31 +0200
Date: Thu, 5 Apr 2001 07:08:31 +0200
From: Ralf Baechle <ralf@oss.sgi.com>
To: Matthew Fredrickson <matt@frednet.dyndns.org>
Cc: jsc6233@ritvax.isc.rit.edu, linux-mips@oss.sgi.com
Subject: Re: your mail
Message-ID: <20010405070831.A11613@bacchus.dhis.org>
References: <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu> <20010404163747.A22469@frednet.dyndns.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010404163747.A22469@frednet.dyndns.org>; from matt@frednet.dyndns.org on Wed, Apr 04, 2001 at 04:37:47PM -0500
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk

On Wed, Apr 04, 2001 at 04:37:47PM -0500, Matthew Fredrickson wrote:

> > hello,
> > Yeah i am trying to compile it while running Irix 6.5. Once i get it all 
> > working I was going to boot into it. Does that make sense?
> > james
> 
> <g>No offense, but not really.  Actually, you'll probably need to start
> off by setting up the x86-mips cross compilers on an x86 linux machine of
> yours and booting the kernel via tftp over the network to get started.  I
> think most of this is covered in the FAQ on the site.  Anyway, I don't
> think it's _ever_ been supported to compile up the kernel in IRIX anyway,
> so your kind of out of luck for that.

You obvious didn't even check.  I assure you that I rarely compile a MIPS
kernel under Linux so if that works, it's coincidental.  Crosscompiling
on IRIX works just fine.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f93Fr5l17314
	for linux-mips-outgoing; Wed, 3 Oct 2001 08:53:05 -0700
Received: from kuolema.infodrom.north.de (kuolema.infodrom.north.de [217.89.86.35])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93Fr0D17311
	for <linux-mips@oss.sgi.com>; Wed, 3 Oct 2001 08:53:01 -0700
Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34])
	by kuolema.infodrom.north.de (Postfix) with ESMTP
	id 051894D73C; Wed,  3 Oct 2001 17:52:45 +0200 (CEST)
Received: by finlandia.infodrom.north.de (Postfix, from userid 501)
	id C509310977; Wed,  3 Oct 2001 17:52:43 +0200 (CEST)
Date: Wed, 3 Oct 2001 17:52:43 +0200
From: Martin Schulze <joey@finlandia.infodrom.north.de>
To: Marian Kafadarov <mkafadarov@it-academy.bg>
Cc: linux-mips@oss.sgi.com
Subject: Re: your mail
Message-ID: <20011003175243.A18353@finlandia.infodrom.north.de>
Reply-To: Martin Schulze <joey@infodrom.north.de>
References: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg>
User-Agent: Mutt/1.3.20i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk

Marian Kafadarov wrote:
> Hello,
> We have DEC station 5000 / 240
> From were we can download Linux distribution and documentation for it and
> what we can do on it.

You could wait until we have finished boot-floppies for this machine
(1-3 weeks) or bootstrap from scratch by using a kernel and a Debian
base system.  Both is available, Karsten can also provide a correct
2.4.x kernel.

I'd rather like to ask you to wait a couple of days/weeks until
boot-floppies are available for this machine and you can use the
regular Debian installation process which will be less painful
than the other.  If you do so, please come back to us in some
days/weeks to find out if things are ready already.

Regards,

	Joey

-- 
All language designers are arrogant.  Goes with the territory...
	-- Larry Wall

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Oct 2002 22:07:57 +0200 (CEST)
Received: from crack.them.org ([65.125.64.184]:18181 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1123891AbSJZUH5>;
	Sat, 26 Oct 2002 22:07:57 +0200
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 185Y9R-0004vy-00; Sat, 26 Oct 2002 16:07:22 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 185XE5-0004A7-00; Sat, 26 Oct 2002 16:08:05 -0400
Date: Sat, 26 Oct 2002 16:08:05 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Zajerko-McKee, Nick" <nmckee@telogy.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: your mail
Message-ID: <20021026200804.GA15684@nevyn.them.org>
References: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 525
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> Hi,
> 
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure.  Was this an oversight or a
> design decision?  I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...

It's probably for compatibility with that other MIPS operating system -
IRIX.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Oct 2002 22:34:57 +0200 (CEST)
Received: from nixon.xkey.com ([209.245.148.124]:18657 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1123891AbSJZUe4>;
	Sat, 26 Oct 2002 22:34:56 +0200
Received: (qmail 22448 invoked from network); 26 Oct 2002 20:34:49 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 26 Oct 2002 20:34:49 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id g9QKW9702281
	for linux-mips@linux-mips.org; Sat, 26 Oct 2002 13:32:09 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Sat, 26 Oct 2002 13:32:09 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: your mail
Message-ID: <20021026133209.B2153@wumpus.attbi.com>
References: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>; from nmckee@telogy.com on Sat, Oct 26, 2002 at 03:48:27PM -0400
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 526
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:

> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure.  Was this an oversight or a
> design decision?  I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...

User programs normally get recompiled, so anything using the proper
includes IS portable.

The issue only appears if you are using binary translation of x86
programs on mips. For example, this is one:

http://www.transitives.com/products.htm

For this, you need to write a system call translation layer which
rearranges things appropriately. An existing example is the o32 layer
in mips64, and soon the n32 layer in mips64.

-- greg

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 Mar 2003 07:25:45 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:12303
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224861AbTC2HZo>; Sat, 29 Mar 2003 07:25:44 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18zAik-0004o9-00; Sat, 29 Mar 2003 08:25:42 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18zAij-00052r-00; Sat, 29 Mar 2003 08:25:41 +0100
Date: Sat, 29 Mar 2003 08:25:41 +0100
To: "Avinash S." <avinash.s@inspiretech.com>
Cc: linux <linux-mips@linux-mips.org>
Subject: Re: your mail
Message-ID: <20030329072541.GD14490@rembrandt.csv.ica.uni-stuttgart.de>
References: <200303290723.h2T7NYq6006229@smtp.inspirtek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303290723.h2T7NYq6006229@smtp.inspirtek.com>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1861
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Avinash S. wrote:
> Hello,
> 
> Im trying to build a kernel config for a big endian IDT79S334 board. I 
> have sucessfully mangaged to get a vmlinux image using Embedix tools for 
> little endian but am having problems with big endian configs. I am using 
> binutils version 2.8. I get an error when i reaches irq.c saying:
                   ^^^
That's _very_ old.

> Unknown ISA level 
> Unknown opcode 'clz'
> 
> im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know 
> how to solve this problem or where can i get a mips-linux-gcc that 
> supports the opcode.

It's the assembler, not the compiler. Upgrade binutils.


Thiemo

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 19:17:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44018 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224861AbTDQSRW>;
	Thu, 17 Apr 2003 19:17:22 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h3HIHAk24000;
	Thu, 17 Apr 2003 11:17:10 -0700
Date: Thu, 17 Apr 2003 11:17:10 -0700
From: Jun Sun <jsun@mvista.com>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: your mail
Message-ID: <20030417111710.F1642@mvista.com>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>; from DennisCastleman@oaktech.com on Thu, Apr 17, 2003 at 10:53:57AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2100
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> ALL
> 
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
>

It really depends on the applications.  The biggest gain from 64bit,
other than the obviously bigger address space, is 64bit data
manipulation.  A single 64bit instruction (add/sub/...) is carried
out by several instructions in 32bit.

If your apps are heavy on 64bit operations, then you gain.
Otherwise I suspect no performance gain or even possibly a little 
worse performance due more stress on cache/memory subsystems.

I am sure others with more 64bit experience probably have more 
to say.  :)


Jun

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Apr 2003 21:14:50 +0100 (BST)
Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:57985
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225223AbTDQUOt>; Thu, 17 Apr 2003 21:14:49 +0100
Received: from localhost.localdomain (greglaptop [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h3HKF3hv001633
	for <linux-mips@linux-mips.org>; Thu, 17 Apr 2003 13:15:03 -0700
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id h3HKF3dI001631
	for linux-mips@linux-mips.org; Thu, 17 Apr 2003 13:15:03 -0700
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 17 Apr 2003 13:15:03 -0700
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: your mail
Message-ID: <20030417201503.GF1345@greglaptop.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL> <20030417111710.F1642@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030417111710.F1642@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2103
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 11:17:10AM -0700, Jun Sun wrote:

> It really depends on the applications.  The biggest gain from 64bit,
> other than the obviously bigger address space, is 64bit data
> manipulation.  A single 64bit instruction (add/sub/...) is carried
> out by several instructions in 32bit.

A big gain is the increased # of registers and better calling
sequence. Everyone sees that, not just people who want to use 64-bit
integers. At the moment you need to run the 64-bit kernel -- and the
new binutils & glibc -- in order to get n32 programs to work.

-- greg

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 01:04:08 +0100 (BST)
Received: from p508B7D9B.dip.t-dialin.net ([IPv6:::ffff:80.139.125.155]:24519
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225227AbTDRAEH>; Fri, 18 Apr 2003 01:04:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h3I03ju17855;
	Fri, 18 Apr 2003 02:03:45 +0200
Date: Fri, 18 Apr 2003 02:03:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: your mail
Message-ID: <20030418020345.A6962@linux-mips.org>
References: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>; from DennisCastleman@oaktech.com on Thu, Apr 17, 2003 at 10:53:57AM -0700
Return-Path: <ralf@linux-mips.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2104
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Apr 2003 01:15:16 +0100 (BST)
Received: from [IPv6:::ffff:207.16.149.110] ([IPv6:::ffff:207.16.149.110]:26312
	"EHLO mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225227AbTDRAPP>; Fri, 18 Apr 2003 01:15:15 +0100
Received: from tlexmail.teralogic.tv (tlexmail [192.168.100.138])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h3I0BlO27345;
	Thu, 17 Apr 2003 17:11:47 -0700 (PDT)
Received: by TLEXMAIL with Internet Mail Service (5.5.2653.19)
	id <22ACPC9C>; Thu, 17 Apr 2003 17:08:36 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E2634102F17@TLEXMAIL>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>,
	Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: RE: your mail
Date: Thu, 17 Apr 2003 17:08:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3053E.A7230FF0"
Return-Path: <DennisCastleman@oaktech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2105
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.com
Precedence: bulk
X-list: linux-mips

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3053E.A7230FF0
Content-Type: text/plain

Thanks Ralf

Looks like I made the correct call when I picked MIPS32 Kernel.
Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,
it's generating code that looks like this

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afbf001c  sw  $ra,28($sp)
   8: afb20018  sw  $s2,24($sp)
   c: afb10014  sw  $s1,20($sp)
  10: afb00010  sw  $s0,16($sp)
  14: 00809021  move  $s2,$a0
  18: 00a08021  move  $s0,$a1
  1c: 00c08821  move  $s1,$a2
  20: 24040001  li  $a0,1
  24: 24050010  li  $a1,16
  28: 3c020000  lui $v0,0x0
  2c: 24420000  addiu $v0,$v0,0

but if I use the 2.95.3 toolchain I build myself it's
generating code that looks like this.

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afb20018  sw  $s2,24($sp)
   8: 00809021  move  $s2,$a0
   c: afb00010  sw  $s0,16($sp)
  10: 00a08021  move  $s0,$a1
  14: afb10014  sw  $s1,20($sp)
  18: 00c08821  move  $s1,$a2
  1c: 24040001  li  $a0,1
  20: 24050010  li  $a1,16
  24: 3c020000  lui $v0,0x0
  28: 24420000  addiu $v0,$v0,0


Any idea whats up MV tool-chain.


Dennis 


-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, April 17, 2003 5:04 PM
To: Dennis Castleman
Cc: linux-mips@linux-mips.org
Subject: Re: your mail


On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

------_=_NextPart_001_01C3053E.A7230FF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: your mail</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks Ralf</FONT>
</P>

<P><FONT SIZE=2>Looks like I made the correct call when I picked MIPS32 Kernel.</FONT>
<BR><FONT SIZE=2>Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,</FONT>
<BR><FONT SIZE=2>it's generating code that looks like this</FONT>
</P>

<P><FONT SIZE=2>0000000000000000 &lt;bitBufferCreate&gt;:</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 0: 27bdffe0&nbsp; addiu $sp,$sp,-32</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 4: afbf001c&nbsp; sw&nbsp; $ra,28($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 8: afb20018&nbsp; sw&nbsp; $s2,24($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; c: afb10014&nbsp; sw&nbsp; $s1,20($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 10: afb00010&nbsp; sw&nbsp; $s0,16($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 14: 00809021&nbsp; move&nbsp; $s2,$a0</FONT>
<BR><FONT SIZE=2>&nbsp; 18: 00a08021&nbsp; move&nbsp; $s0,$a1</FONT>
<BR><FONT SIZE=2>&nbsp; 1c: 00c08821&nbsp; move&nbsp; $s1,$a2</FONT>
<BR><FONT SIZE=2>&nbsp; 20: 24040001&nbsp; li&nbsp; $a0,1</FONT>
<BR><FONT SIZE=2>&nbsp; 24: 24050010&nbsp; li&nbsp; $a1,16</FONT>
<BR><FONT SIZE=2>&nbsp; 28: 3c020000&nbsp; lui $v0,0x0</FONT>
<BR><FONT SIZE=2>&nbsp; 2c: 24420000&nbsp; addiu $v0,$v0,0</FONT>
</P>

<P><FONT SIZE=2>but if I use the 2.95.3 toolchain I build myself it's</FONT>
<BR><FONT SIZE=2>generating code that looks like this.</FONT>
</P>

<P><FONT SIZE=2>0000000000000000 &lt;bitBufferCreate&gt;:</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 0: 27bdffe0&nbsp; addiu $sp,$sp,-32</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 4: afb20018&nbsp; sw&nbsp; $s2,24($sp)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; 8: 00809021&nbsp; move&nbsp; $s2,$a0</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; c: afb00010&nbsp; sw&nbsp; $s0,16($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 10: 00a08021&nbsp; move&nbsp; $s0,$a1</FONT>
<BR><FONT SIZE=2>&nbsp; 14: afb10014&nbsp; sw&nbsp; $s1,20($sp)</FONT>
<BR><FONT SIZE=2>&nbsp; 18: 00c08821&nbsp; move&nbsp; $s1,$a2</FONT>
<BR><FONT SIZE=2>&nbsp; 1c: 24040001&nbsp; li&nbsp; $a0,1</FONT>
<BR><FONT SIZE=2>&nbsp; 20: 24050010&nbsp; li&nbsp; $a1,16</FONT>
<BR><FONT SIZE=2>&nbsp; 24: 3c020000&nbsp; lui $v0,0x0</FONT>
<BR><FONT SIZE=2>&nbsp; 28: 24420000&nbsp; addiu $v0,$v0,0</FONT>
</P>
<BR>

<P><FONT SIZE=2>Any idea whats up MV tool-chain.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Dennis </FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Ralf Baechle [<A HREF="mailto:ralf@linux-mips.org">mailto:ralf@linux-mips.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, April 17, 2003 5:04 PM</FONT>
<BR><FONT SIZE=2>To: Dennis Castleman</FONT>
<BR><FONT SIZE=2>Cc: linux-mips@linux-mips.org</FONT>
<BR><FONT SIZE=2>Subject: Re: your mail</FONT>
</P>
<BR>

<P><FONT SIZE=2>On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; Anybody know the performance differences I can expect using a MIPS 5K core</FONT>
<BR><FONT SIZE=2>&gt; @250 Mhz in 64bit mode versus 32bit mode?</FONT>
</P>

<P><FONT SIZE=2>As a rule of thumb - less performance.&nbsp; 64-bit code is typically larger</FONT>
<BR><FONT SIZE=2>resulting in lower cache hit rate.&nbsp; And since performance optimization</FONT>
<BR><FONT SIZE=2>these days is essentially equivalent to maximising the cache hit rate</FONT>
<BR><FONT SIZE=2>going 64-bit usually means a performance drop due to the drastically</FONT>
<BR><FONT SIZE=2>larger size of code and data.</FONT>
</P>

<P><FONT SIZE=2>On the positive side for 64-bit stuff there's the possibility to do</FONT>
<BR><FONT SIZE=2>64-bit computations with just one instruction, move data with less</FONT>
<BR><FONT SIZE=2>instructions, use twice as many double precission fp registers that are</FONT>
<BR><FONT SIZE=2>offered by 64-bit ABIs and more calling sequences.</FONT>
</P>

<P><FONT SIZE=2>The first two paragraphs were sort of a generic statement regarding</FONT>
<BR><FONT SIZE=2>32-bit vs. 64-bit software on MIPS processors and affect both kernel and</FONT>
<BR><FONT SIZE=2>userspace.&nbsp; There's a few additional issues with the Linux kernel.</FONT>
<BR><FONT SIZE=2>The 32-bit kernels requires all memory to be addressable through KSEG0</FONT>
<BR><FONT SIZE=2>which limits it to at most 512MB; typically the limit is more like 256MB.</FONT>
<BR><FONT SIZE=2>Memory above 512MB physical address can only be used as highmem.&nbsp; That's</FONT>
<BR><FONT SIZE=2>fairly inefficient and requires alot of special care when writing new</FONT>
<BR><FONT SIZE=2>kernel software.&nbsp; For processors that suffer from virtual aliases in</FONT>
<BR><FONT SIZE=2>their data cache highmem currently is frighteningly inefficient - and</FONT>
<BR><FONT SIZE=2>high memory pressure on lowmem doesn't help either.&nbsp; So from a certain</FONT>
<BR><FONT SIZE=2>point on that's simply making a 64-bit kernel is simply the better</FONT>
<BR><FONT SIZE=2>idea - even for running 32-bit software.&nbsp; That in particular applies</FONT>
<BR><FONT SIZE=2>to very I/O intensive stuff.</FONT>
</P>

<P><FONT SIZE=2>In short - the right choice is a tradeoff between the hardware platform</FONT>
<BR><FONT SIZE=2>and the application's requirements.&nbsp; Choose wrong and you'll curse</FONT>
<BR><FONT SIZE=2>loudly :-)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Ralf</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3053E.A7230FF0--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Apr 2005 12:03:48 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:5655 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225970AbVD2LDe>; Fri, 29 Apr 2005 12:03:34 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j3TB30Vk017145;
	Fri, 29 Apr 2005 12:03:00 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j3TB2xoc017144;
	Fri, 29 Apr 2005 12:02:59 +0100
Date:	Fri, 29 Apr 2005 12:02:58 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	linux-mips@linux-mips.org, TheNop@gmx.net
Subject: Re: your mail
Message-ID: <20050429110258.GE5951@linux-mips.org>
References: <20050428191608Z8225923-1340+6320@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050428191608Z8225923-1340+6320@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 7836
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Apr 28, 2005 at 03:15:49PM -0400, Bryan Althouse wrote:

> I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> Somehow, I am unable to compile the kernel.  I have tried the 2.6.10 kernel
> trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> linux-mips.  I am using the 3.3.x cross compile tools from
> ftp.pmc-sierra.com .  The 2.4.x kernels from PMC compile fine.
> 
> In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
>        Make[3]: *** [drivers/char/agp/backend.o] Error 1

Configuring AGP support for a MIPS kernel is obviously nonsense.  Disable
CONFIG_AGP.

> In the case of 2.6.12 from linux-mips, my error looks like:
> 	drivers/net/titan_ge.c1950: error: 'titan_device_remove"  undeclared
> here (not in a function)

Whoops, a bug.  The function indeed doesn't exist even though it should,
will fix that.  You will hit this bug only if compiling the titan driver
as a module, so workaround set CONFIG_TITAN_GE=y.  Which for the typical
titan-based device seems to be the preferable choice anyway.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jan 2008 17:51:31 +0000 (GMT)
Received: from localhost.localdomain ([127.0.0.1]:26768 "EHLO
	dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP
	id S28577026AbYA1Rv3 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 28 Jan 2008 17:51:29 +0000
Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1])
	by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m0SHpSif015601;
	Mon, 28 Jan 2008 17:51:28 GMT
Received: (from ralf@localhost)
	by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m0SHpS3b015600;
	Mon, 28 Jan 2008 17:51:28 GMT
Date:	Mon, 28 Jan 2008 17:51:28 +0000
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: your mail
Message-ID: <20080128175128.GA15115@linux-mips.org>
References: <20080122000026.GN28842@networkno.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080122000026.GN28842@networkno.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 18153
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 22, 2008 at 12:00:26AM +0000, Thiemo Seufer wrote:

> This patch moves the micro-assembler in a separate implementation, as
> it is useful for further run-time optimizations. The only change in
> behaviour is cutting down printk noise at kernel startup time.
> 
> Checkpatch complains about macro parameters which aren't protected by
> parentheses. I believe this is a flaw in checkpatch, the paste operator
> used in those macros won't work with parenthesised parameters.
> 
> Tested on:
> - Qemu 32-bit little endian
> - BCM1480 64-bit big endian
> 
> 
> Thiemo
> 
> 
> ---
> Split the micro-assembler from tlbex.c.
> 
> Signed-off-by:  Thiemo Seufer <ths@networkno.de>

Looks technically ok but conflicts with these 7 other patches which also
touch arch/mips/mm/tlbex.c:

Please keep all the stuff the stuff that should go into the commit
message - and only that - above the "---" tearline.  git-am will drop
anything below it and friendly greetings, signatures etc. should not go
into the log message so keep that below the tearoff line.

commit 699a78e99f302003ae6d6090bf7f35eb69b772e0
Author: Manuel Lauss <mano@roarinelk.homelinux.net>
Date:   Thu Dec 6 09:07:55 2007 +0100

    [MIPS] Alchemy: Au1210/Au1250 CPU support
    
    This patch adds IDs for new Au1200 variants: Au1210 and Au1250.
    They are essentially identical to the Au1200 except for the Au1210
    which has a different SoC-ID in the PRId register [bits 31:24].
    The Au1250 is a "Au1200 V0.2".
    
    Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 56bccd5921f7b1160ddab0f9c3e9cc227ecd9aef
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:17 2007 +0200

    [MIPS] tlbex.c: cleanup debug code
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 97432dc56d464006a62b1cd3ee6484828bde816c
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:16 2007 +0200

    [MIPS] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 82e27810cd28e4322bd400640c8627ceacfc29f5
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:15 2007 +0200

    [MIPS] tlbex.c: cleanup include files
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit b849ac81b87278c9b9e17aef8f4d82a30578ec93
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:14 2007 +0200

    [MIPS] tlbex.c: Cleanup __init usages.
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit bf672b2f700d031d933c7dadcd9fae5edaa019b4
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Tue Oct 23 12:43:25 2007 +0100

    [MIPS] R4000/R4400 daddiu erratum workaround
    
     This complements the generic R4000/R4400 errata workaround code and adds
    bits for the daddiu problem.  In most places it just modifies handwritten
    assembly code so that the assembler is allowed to use a temporary register
    as daddiu may now be treated as a macro that expands to a sequence of li
    and daddu.  It is the AT register or, where AT is unavailable or used
    explicitly for another purpose, an explicitly-named register is selected,
    using the .set at=<reg> feature added recently to gas.  This feature is
    only used if CONFIG_CPU_DADDI_WORKAROUNDS has been set, so if the
    workaround remains disabled, the required version of binutils stays
    unchanged.
    
     Similarly, daddiu instructions put in branch delay slots in noreorder
    fragments are now taken out of them and the assembler is allowed to
    reorder them itself as possible (which it does making the whole idea of
    scheduling them into delay slots manually questionable).
    
     Also in the very few places where such a simple conversion was not
    possible, a handcoded longer sequence is implemented.
    
     Other than that there are changes to code responsible for building the
    TLB fault and page clear/copy handlers to avoid daddiu as appropriate.
    These are only effective if the erratum is verified to be present at the
    run time.
    
     Finally there is a trivial update to __delay(), because it uses daddiu in
    a branch delay slot.
    
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 2d220349159729f143570673f8752aafd6d8da74
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Mon Jan 28 17:14:10 2008 +0000

    [MIPS] tlbex: Cleanup handling of R2 hazards in TLB handlers.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

But I'm really happing to see the generalization we've been talking about
to finally proceed.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Mar 2018 23:32:37 +0100 (CET)
Received: from 9pmail.ess.barracuda.com ([64.235.154.211]:53051 "EHLO
        9pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK)
        by eddie.linux-mips.org with ESMTP id S23990401AbeCIWca3PQ0s (ORCPT
        <rfc822;linux-mips@linux-mips.org>); Fri, 9 Mar 2018 23:32:30 +0100
Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1403.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 09 Mar 2018 22:31:55 +0000
Received: from localhost (192.168.154.110) by MIPSMAIL01.mipstec.com
 (10.20.43.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 9 Mar 2018
 14:31:53 -0800
Date:   Fri, 9 Mar 2018 22:31:48 +0000
From:   James Hogan <james.hogan@mips.com>
To:     Paul Cercueil <paul@crapouillou.net>
CC:     Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        <linux-mmc@vger.kernel.org>, <linux-mips@linux-mips.org>,
        Alex Smith <alex.smith@imgtec.com>
Subject: Re: your mail
Message-ID: <20180309223147.GB18133@jhogan-linux.mipstec.com>
References: <20180309151219.18723-1-ezequiel@vanguardiasur.com.ar>
 <20180309151219.18723-9-ezequiel@vanguardiasur.com.ar>
 <df6880caf0291e32250deafeb4c71476@crapouillou.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6"
Content-Disposition: inline
In-Reply-To: <df6880caf0291e32250deafeb4c71476@crapouillou.net>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Originating-IP: [192.168.154.110]
X-BESS-ID: 1520634713-321459-21834-11893-4
X-BESS-VER: 2018.2-r1803082101
X-BESS-Apparent-Source-IP: 12.201.5.28
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.190883
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- --------------------------------
        0.00 BSF_BESS_OUTBOUND      META: BESS Outbound 
X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND
X-BESS-BRTS-Status: 1
Return-Path: <James.Hogan@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 62895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: james.hogan@mips.com
Precedence: bulk
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
X-List-ID: linux-mips <linux-mips.eddie.linux-mips.org>
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
X-list: linux-mips

--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a =C3=A9crit=C2=A0:
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> >   * trigger is when data words in MSC_TXFIFO is < 8.
> >   */
> >  #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > +	void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > +	void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > +	uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> >  };
>=20
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and=20
> is
> 30 lines shorter.
>=20
> I'm not terribly against either, so if nobody else bug on that, feel=20
> free
> to ignore my comment.

I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.

Cheers
James

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAlqjC00ACgkQbAtpk944
dnp5rw/+JdDz1OYUmiVyUElKgx994CGzHqb/PbX9+oitMmQR3RbUYNNaOEdZ2icn
lWLSobRUXvvleRjVHKJKNWZobiS7jyavTydtafaVhEOf5V40aph5iciHK1qX5k5c
ByTjmXDnFgCato6bQT/HrMIxCsZLlsTXqD9yANUnSGDb1Q1SifByXP3tzOfBNHHT
0hoCiYJAxU4NhnJvJ8eSfdFLyMcezPLb60RnMxD84JywVm3vHciANCFYiJRAjqfH
c8WnaIGb/0cL87a1zB9Pj7Mfif0A05c895+3FQRAZZjl4HzfOC35pzJVRBTade08
uHDBHz7MKhjAjX7+CRKC8y0xI+usurJ8VKeHZ40Dpn/ET3VBdBqlp5JkaK5Am2p6
3tOaUevG+b0zEJLZqxecF/s1oU6XgHo/cyA6KFDUkEUKLBSC7r/npybQvZVmjtAT
WORFJNynswSVqONd89gW7+3Pc8tFVGsSbWpNkrUq57WajahK5JEwE63FbvZR1F1q
soJlmPlK+UDYXDiiMy1tfOvx+SRbR0XnHfm4HYDeo0VLO1MB8W+JnjcUGVzG07T3
a0wwNcHmdnZrgBHr0a3Zmadt8lU6OAgkGtdsvyrq4+OZ/t9447tX3bIXvcH5w1yf
38Xd7nOVop0C8QQs/bpYyjN8Oll9RbgHyq4kkK3y4f7FaEbT3b4=
=Jx9X
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Aug 2018 22:24:08 +0200 (CEST)
Received: from mail-co1nam03on0112.outbound.protection.outlook.com ([104.47.40.112]:55022
        "EHLO NAM03-CO1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP
        id S23994590AbeHaUYE2Ufcx (ORCPT <rfc822;linux-mips@linux-mips.org>);
        Fri, 31 Aug 2018 22:24:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=wavesemi.onmicrosoft.com; s=selector1-wavecomp-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nznYOGtk4qZu6av87MxS+/ApZn8zljXrS9zZXfIeHvc=;
 b=PtRgqFEjS0a73ABNdMykIkcmYVZr75+Qdhb8vdxLnVguZ8cmx4x/E3a5bwpu9v2+L+KIWZKWeU9rgFjTsUDBJgAowO4Z+9lugl0zBq73hMF9iO5Fb39S+EbPVFD+DxBTadXbWqckoO0Vig68O29LRDcjiWnP0vZZ7/adKyFj+xU=
Received: from localhost (4.16.204.77) by
 BYAPR08MB4933.namprd08.prod.outlook.com (2603:10b6:a03:6a::14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.1080.15; Fri, 31 Aug 2018 20:23:53 +0000
Date:   Fri, 31 Aug 2018 13:23:49 -0700
From:   Paul Burton <paul.burton@mips.com>
To:     Christoph Hellwig <hch@lst.de>
Cc:     iommu@lists.linux-foundation.org,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Robin Murphy <robin.murphy@arm.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20180831202349.xcz45jjcy7xvx3yk@pburton-laptop>
References: <20180827145032.9522-1-hch@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180827145032.9522-1-hch@lst.de>
User-Agent: NeoMutt/20180716
X-Originating-IP: [4.16.204.77]
X-ClientProxiedBy: DM6PR08CA0036.namprd08.prod.outlook.com
 (2603:10b6:5:80::49) To BYAPR08MB4933.namprd08.prod.outlook.com
 (2603:10b6:a03:6a::14)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1214694d-0cd2-468d-efdd-08d60f7fabf8
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020);SRVR:BYAPR08MB4933;
X-Microsoft-Exchange-Diagnostics: 1;BYAPR08MB4933;3:qdZZUpgKHXqCBqatEY+U5dS+oEB3w6nkMSVg5FkFLwLR9U0rs1gENoiXQYWTsXWx4n4FXw82hpnGB/u1xa6nhzqratpOCifWobXHOrH5JnVgb3N9LP7NPmdjRqagAJ9CTxnZSf0I9vimWSOT/onVCwvMDK27Uqe0Mrv0r+MENynmTOa40atF7OA8WnhUQg98DgzAsFbnkQtmaDTE3Sm/H1RKXWYy4kcpgLKPrrCJCfjJ4IDHaSNvyj51gZxT7P3E;25:tmrHqxtIY6+CnLwgd7A0stFCiDG3VJlMfVzgfcmvM5NHGKy+MxE1ceL97r9n2/RxMGND+RKr1RQhnfMiCVDYuPHa4x57a3gLVzJRBb1CoSqSPPAdhGwtaTJloAh24M2rmCaKdIsyoxtHQ4xAicw0rcZZ6y3vOeB8mJ3F0zjIpy2aMtGeamJ0dHyRiJR0a+NT+6T4mfSwcM9/2yxs7zd5lBcOYvwad3J9odPVU/4Q/TITSH1c4KvF62yldhkuwaIs2DhUEqYQqr0gyuUjeq8K5MAW/Bf4c+6yNtMiza886gCf785gA2kwcuOn7PnzmpQATdsSNgnQCHGC1tMq8WcDTQ==;31:yfpIJnjhylev9EUGXMEyS+H4EYVXQyZPW8TzLsu8GUYQg7kECtyl+RMUecxHYgmclKBHSiBx3LFRnNyPDTKiwsuwlrUGo+zM4r+bqJUv0ngyvicx/rzdGd/bQdtuh+VNh2LUFH6HuCMdG3N6+N7z9RS4M+1MNTjsIgJMKhV5z1KrIoeVtxlc6o3XhaX7l7R7gEEgoZHjdzm5534OpAJ5bEIws114ThQRBE+Yr6t4I+c=
X-MS-TrafficTypeDiagnostic: BYAPR08MB4933:
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=pburton@wavecomp.com; 
X-Microsoft-Exchange-Diagnostics: 1;BYAPR08MB4933;20:6B00CnnT2/pNY4/L/h1SdTWxUYA1o+/FlV0LFoq9ZYFZHfvQq/YBm3SfE+QWnllf5fb/rhQBDT0jlK2NoPDpgaXjBYv0kQwdjfvyzMbby3lW//SaWP4KFgkKNMtNVqyzhGjmIhdH+ZMj73RYsE3wkgto35e8KXCDglIyTCJNvPvMpKUipF8sBAihCUoeGoc5Uhh9TYM8xEJRTr17Rd8cQPYUlsA1pFkE0MNVM2DkTYmykTbxIPgY3CTU9MkXuyUy;4:cXGtAahbXahQSgkGjjUBb9WwPTm2S6Xlv9lbCmL7Oez/N+4O311y3OScsKWjAXV67Cfi/F4gAo4wIUnYjp3UGY0HHUcst+kw1fse8xQiu2TRM0wFjL5CtG4eRo4XqfvvrfpuzhYUe0u2u8btesyz8zCSgRVQnfRNTUE9PO5jVNSIRnqElN0IkrU+UUZQwgRlUMH/Um8MehHwdWVb+34TBgTsGhuCM5Q5dWn9UPp1n29zG3o4T1wm/oZowRVBoZMaBnMa+dBRhYJRBGw6y1pvNw==
X-Microsoft-Antispam-PRVS: <BYAPR08MB4933AA2D982C4F38AD250C33C10F0@BYAPR08MB4933.namprd08.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(944501410)(52105095)(93006095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699016);SRVR:BYAPR08MB4933;BCL:0;PCL:0;RULEID:;SRVR:BYAPR08MB4933;
X-Forefront-PRVS: 07817FCC2D
X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6069001)(7916004)(366004)(136003)(376002)(39840400004)(346002)(396003)(199004)(189003)(97736004)(33896004)(44832011)(11346002)(956004)(47776003)(316002)(54906003)(26005)(7116003)(305945005)(76176011)(6306002)(58126008)(53936002)(6666003)(68736007)(66066001)(478600001)(6116002)(3846002)(33716001)(221733001)(229853002)(23726003)(476003)(5660300001)(486006)(50466002)(446003)(2906002)(1076002)(42882007)(76506005)(8936002)(16526019)(25786009)(81166006)(186003)(81156014)(105586002)(52116002)(8676002)(386003)(6496006)(16586007)(9686003)(6246003)(966005)(6486002)(7736002)(3480700004)(6916009)(4326008)(106356001)(111123002);DIR:OUT;SFP:1102;SCL:1;SRVR:BYAPR08MB4933;H:localhost;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
Received-SPF: None (protection.outlook.com: wavecomp.com does not designate
 permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BYAPR08MB4933;23:keU9RdKCMYAF+VQyE9JBYAneB1LTI3SB5dc05HUD7?=
 =?us-ascii?Q?8HRkO+uI5GFxvNs5L6JArXGVZo69L7aLUa0BxArg3srS6AdCm476L6spAS4j?=
 =?us-ascii?Q?+LiR0C7jvaDZ1btvBnGRmvq/bX8a2agzA4D6pfO2tCGmu9N9dwRr+rbzUXMF?=
 =?us-ascii?Q?/M0hD0iDG735irQIJQcJJRmIWf+smjvH7dFKGajPpheA4Io728mbgwgpuEr7?=
 =?us-ascii?Q?0TmAnsjik1oHzcIRIkA06zgSdowGdQuvMTep8p4NUv5y8AXK2MKFTztP3fMg?=
 =?us-ascii?Q?IQ3r3ULdutM2qkYgNYlATZ8SuXId5iZCKJo1ef4/Ye4ffSz46YasVyh3eMqC?=
 =?us-ascii?Q?EgAFiH/S6wOGGg/L5+sXDATIC6W5vmhNzIT6lLSWQgrveab79qUdebEz53Ws?=
 =?us-ascii?Q?eMPageMwtbxGjnu1clSSAxM6svskeGo/KUZ18MXaj4TRbz4fTCfmy6sUEigs?=
 =?us-ascii?Q?Ld24u7/DF/SoEc6aE17sIyPymqEsSzEwum+C8QaRf7PpSQwl8EnO+GxzFRUn?=
 =?us-ascii?Q?j/40Hs50xQdZLcm8ymHYKxKRU6oBTTEZs1cRMZ36t1VrcfDLI5mqUdABRrpl?=
 =?us-ascii?Q?taAszTbE8z9Ej6KyF7LNRxrN/uiP4/C9KAo9jzra3scFAk5qtvARTmVqataq?=
 =?us-ascii?Q?BJJ83bYipi9Jc/RLFO1jJQtwLhhEtDcja9Y/5Af3yGHTlGw6RUPCQJPb1mfV?=
 =?us-ascii?Q?vulV0xGhfZsnGqsCmFBot2W30Ko8QkvbPqhcMy60ydduIl8w14BaSD9YcEo7?=
 =?us-ascii?Q?hb7bke8FP+sd4nRCtGW6BNTJ30Cy9UIQAUnCo8CcyDLtXHc7s0z01egq0cob?=
 =?us-ascii?Q?6rhnUojxTevRRbHZ48FerO7C5PacRSlr/BylSoIXCuH5ljxgs+jW9cXTyGA3?=
 =?us-ascii?Q?l675SzcZpYAX1bWTcKQxkkYEUyRoymvG/2teecGaODMaRxR9ecFOkpriFBn8?=
 =?us-ascii?Q?z1XvnRxx5ZtcrDFYnlDXow3QLkpXE5BRPO4azvdIhcAtrmxm5RgkmZWrnUmm?=
 =?us-ascii?Q?kX0nHby/VpleERAiMAg6lu+sQpbl4acsvRCTyf7HlYkLFd+GDWDAPCMyBrK1?=
 =?us-ascii?Q?XN8e2SjgyZ0Vsou3DKJ7feY1g5UDcNwHAcfUds6/2tNjKW7NUcYJ7etF3/3b?=
 =?us-ascii?Q?OmoyIa2Vg9TlspUCsN1LtlIc06YtfNRCS0uOehdWPa/xV1aMC6ITDlszvVDh?=
 =?us-ascii?Q?cwSxfLQjJmZAaWbLDsrIMogYNhb90b0f/P+1lOHiBIRZCWlLlsAV2UalDXLn?=
 =?us-ascii?Q?qSgettwdWuDDoGfrL+wCPxtfyQ725TFx3yngH4LqRF/Ghv8Yoiqa+0OQQtgw?=
 =?us-ascii?Q?+sG5NtzWlS80vSck0NMmM965tNJKkMA1edQHfdFDsU3DhujxPjbRkRAXy70r?=
 =?us-ascii?Q?gHGNt3aTcfzS/KF/aiSwt4j37hM43wJZ1yqXwswlxQbuQJSS7wIL3hXWxgF1?=
 =?us-ascii?Q?qdSx/z/ew=3D=3D?=
X-Microsoft-Antispam-Message-Info: z9/xY3ivPCBaiAlfPFOvSPeT07qNUjwPS444YOfUs18ftbSrmJzr0TlT0twZ208Qr/Nvj/d+nnxsny4zehHROQWXrRFDqbsl1gPuyRVNYcO7zUSuzEk9Y73LObYh9lJAP9AW0hWfh93NgZdEqYaXGe1i+/Xhm3vHm8wV2C7lFGBGnt892KFQrL6YJob1vhFvr/rXLkQKEHSizANvrfN7+JaHAQooTIKBidLBkSuV2xW+j8NGTdKsfIoW6CgOmA2KONyPNu+X7jmdGh88r4f9FLIFyDIYI46K1ObtzQXm4u5Lxg4s+sUz0wX9Ngi0Ql6RPCTyAmqsGSRft2CoVVD18dCBNUJsZw2ODtevBc7fONE=
X-Microsoft-Exchange-Diagnostics: 1;BYAPR08MB4933;6:Ap86ZybY2UOikk1IXg0Z/FPjuE+PuOrZ0rL1rnK03sRBSJFamPaSBs9GoPEvzjHFLc3sJhrqMHZs/Boy5QWIQxGEhUqr3QO5ZuozHV4VFibDco/QOc71fAxDX4ptZTQzL/8yUfzYw35CohTab8qjf8WRKq929MlbK4U+WcB9pHgx+JRUV8NVB3DRtyQMUHQCEwmDK/TMaUXnwotqJ0l0tTEtSWNQn/XpLCDaUHp73vje4GAZjQ4C4ZRxXRlrGvnOnPyqkIbd/Sssr0zKXNsu6hAFvWvUZheplsqj1Gf+uXLAzaXvwi/rvb2R8Jsx7MZmrJspWT0nFXMHp8A/E1x2ekJ+fPb4kXXsLU5eYnM1dYPEQSMc03voJrLnZ10FOTZciF/AMjbA+FUnzOyv2IZv0+Morwb9GmwFbXBQ+gZ0J++Yker4ag7EVgZ2mx6+w2X2FDYUHbXt/DVi0VCM5vJywg==;5:sBvTYb+MqLtgusnCZWnDvqpPPGU/z6t15wk/mcvS2adVoRdaKEOZZQcgN0Fe44fnZej/UEYFkWh3BAGAUg7ag4nfEWKfb1l1U6i5Td/M8nPCdDZjlqcS0NCi6iK8rCnU3Jk/rHUfafjYEZi8mPRz3gEG3U4mqrnrG+fkPFFYAb0=;7:W7SS3yICln2nfTF9+x33FknPQi8vk+DSqXp8+mX2iR3fp68gujUW7+aBUlCq3oEr024S9gmQLhksls1DNavjgz307Vjpq0HXYimfXFcHwJMsM2d1Mv3ArXI2XvVonwcQAwzS+qvo/6zV3Oe9NUJ7Giz9F9mQUYXxx5CD4NTZ48MB5+MVFeWSPfBkCPYdlwSts6SLTnZORTtj7ziTsmHhk+0uaqVveRxAo3tLZFb0tvBOMMyHm2sG9x/G6YuKI6BU
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mips.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2018 20:23:53.7797 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1214694d-0cd2-468d-efdd-08d60f7fabf8
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 463607d3-1db3-40a0-8a29-970c56230104
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4933
Return-Path: <pburton@wavecomp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 65830
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: paul.burton@mips.com
Precedence: bulk
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
X-List-ID: linux-mips <linux-mips.eddie.linux-mips.org>
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
X-list: linux-mips

Hi Christoph,

On Mon, Aug 27, 2018 at 04:50:27PM +0200, Christoph Hellwig wrote:
> Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
> 
> While most architectures are either always or never dma coherent for a
> given build, the arm, arm64, mips and soon arc architectures can have
> different dma coherent settings on a per-device basis.  Additionally
> some mips builds can decide at boot time if dma is coherent or not.
> 
> I've started to look into handling noncoherent dma in swiotlb, and
> moving the dma-iommu ops into common code [1], and for that we need a
> generic way to check if a given device is coherent or not.  Moving
> this flag into struct device also simplifies the conditionally coherent
> architecture implementations.
> 
> These patches are also available in a git tree given that they have
> a few previous posted dependencies:
> 
>     git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
> 
> Gitweb:
> 
>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge

Apart from the nits in patch 2, these look sane to me from a MIPS
perspective, so for patches 1-4:

    Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts

Thanks,
    Paul

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=uxCP=6V=vger.kernel.org=linux-mips-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-10.2 required=3.0
	tests=HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1
	autolearn=unavailable autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 926F8C38A2A
	for <linux-mips@archiver.kernel.org>; Thu,  7 May 2020 11:43:35 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 7D7CC24957
	for <linux-mips@archiver.kernel.org>; Thu,  7 May 2020 11:43:35 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726797AbgEGLnZ (ORCPT <rfc822;linux-mips@archiver.kernel.org>);
        Thu, 7 May 2020 07:43:25 -0400
Received: from elvis.franken.de ([193.175.24.41]:43620 "EHLO elvis.franken.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725914AbgEGLnX (ORCPT <rfc822;linux-mips@vger.kernel.org>);
        Thu, 7 May 2020 07:43:23 -0400
Received: from uucp (helo=alpha)
        by elvis.franken.de with local-bsmtp (Exim 3.36 #1)
        id 1jWevq-00081e-02; Thu, 07 May 2020 13:43:14 +0200
Received: by alpha.franken.de (Postfix, from userid 1000)
        id 95D7EC0409; Thu,  7 May 2020 13:00:36 +0200 (CEST)
Date:   Thu, 7 May 2020 13:00:36 +0200
From:   Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To:     Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc:     linux-mips@vger.kernel.org, clang-built-linux@googlegroups.com,
        "Maciej W . Rozycki" <macro@linux-mips.org>,
        Fangrui Song <maskray@google.com>,
        Kees Cook <keescook@chromium.org>,
        Nathan Chancellor <natechancellor@gmail.com>,
        Paul Burton <paulburton@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Jouni Hogander <jouni.hogander@unikie.com>,
        Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>,
        Borislav Petkov <bp@suse.de>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20200507110036.GC11616@alpha.franken.de>
References: <20200506055245.3013374-1-jiaxun.yang@flygoat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200506055245.3013374-1-jiaxun.yang@flygoat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-mips-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-mips.vger.kernel.org>
X-Mailing-List: linux-mips@vger.kernel.org

On Wed, May 06, 2020 at 01:52:45PM +0800, Jiaxun Yang wrote:
> Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
> In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>
> 
> LLD failed to link vmlinux with 64bit load address for 32bit ELF
> while bfd will strip 64bit address into 32bit silently.
> To fix LLD build, we should truncate load address provided by platform
> into 32bit for 32bit kernel.
> 
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/786
> Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
> Reviewed-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> Cc: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> V2: Take MaskRay's shell magic.
> 
> V3: After spent an hour on dealing with special character issue in
> Makefile, I gave up to do shell hacks and write a util in C instead.
> Thanks Maciej for pointing out Makefile variable problem.
> 
> v4: Finally we managed to find a Makefile method to do it properly
> thanks to Kees. As it's too far from the initial version, I removed
> Review & Test tag from Nick and Fangrui and Cc instead.
> 
> v5: Care vmlinuz as well.
> 
> v6: Rename to LIKER_LOAD_ADDRESS 
> ---
>  arch/mips/Makefile                 | 13 ++++++++++++-
>  arch/mips/boot/compressed/Makefile |  2 +-
>  arch/mips/kernel/vmlinux.lds.S     |  2 +-
>  3 files changed, 14 insertions(+), 3 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-ID: <199708091741.TAA09294@informatik.uni-koblenz.de>
Subject: Re: your mail
Date: Sat, 9 Aug 1997 19:41:39 +0200 (MET DST)
In-Reply-To: <Pine.LNX.3.95.970809175116.19882B-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 06:16:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
To: Vincent Renardias <vincent@waw.com>
Cc: linux@cthulhu.engr.sgi.com
Message-ID: <19970809174139.QxJ9L4M9RnNGzv8z2f0_gazUVnm2mIIu8K1c9fP_qd8@z>

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-ID: <199708091942.VAA22164@informatik.uni-koblenz.de>
Subject: Re: your mail
Date: Sat, 9 Aug 1997 21:42:38 +0200 (MET DST)
In-Reply-To: <Pine.LNX.3.95.970809195755.24185B-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 08:40:06 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
To: Vincent Renardias <vincent@waw.com>
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
Message-ID: <19970809194238.tfzlUcPu7gMYSCBUgg_L9cgfSsV7lSq4yRN_15Dl0g8@z>

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Message-ID: <199708092112.XAA01472@informatik.uni-koblenz.de>
Subject: Re: your mail
Date: Sat, 9 Aug 1997 23:11:56 +0200 (MET DST)
In-Reply-To: <Pine.LNX.3.95.970809214814.29239A-100000@odin.waw.com> from "Vincent Renardias" at Aug 9, 97 10:05:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
To: Vincent Renardias <vincent@waw.com>
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
Message-ID: <19970809211156.JfVlYDx6VV-20lpL-znB_vvDq0jiG50FwmaZyOlqX8c@z>

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux@cthulhu.engr.sgi.com>
From: Mike Shaver <shaver@neon.ingenia.ca>
Message-ID: <199708092253.SAA17511@neon.ingenia.ca>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.3.95.970809214814.29239A-100000@odin.waw.com> from Vincent Renardias at "Aug 9, 97 10:05:02 pm"
Date: Sat, 9 Aug 1997 18:53:58 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux@cthulhu.engr.sgi.com
To: Vincent Renardias <vincent@waw.com>
Cc: ralf@mailhost.uni-koblenz.de, linux@cthulhu.engr.sgi.com
Message-ID: <19970809225358.TR8ixc2rVeBDY3u99_77hwhBcEV2VchGLgqYOATF8lo@z>

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from 9pmail.ess.barracuda.com ([64.235.154.211]:53051 "EHLO
        9pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK)
        by eddie.linux-mips.org with ESMTP id S23990401AbeCIWca3PQ0s (ORCPT
        <rfc822;linux-mips@linux-mips.org>); Fri, 9 Mar 2018 23:32:30 +0100
Date: Fri, 9 Mar 2018 22:31:48 +0000
From: James Hogan <james.hogan@mips.com>
Subject: Re: your mail
Message-ID: <20180309223147.GB18133@jhogan-linux.mipstec.com>
References: <20180309151219.18723-1-ezequiel@vanguardiasur.com.ar>
 <20180309151219.18723-9-ezequiel@vanguardiasur.com.ar>
 <df6880caf0291e32250deafeb4c71476@crapouillou.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6"
Content-Disposition: inline
In-Reply-To: <df6880caf0291e32250deafeb4c71476@crapouillou.net>
Return-Path: <James.Hogan@mips.com>
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>, Ulf Hansson <ulf.hansson@linaro.org>, linux-mmc@vger.kernel.org, linux-mips@linux-mips.org, Alex Smith <alex.smith@imgtec.com>
Message-ID: <20180309223148.c5sg-jugD2qPd5lfTJpmwHCTkS75Jd5LfLKY0wNpExA@z>

--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a =C3=A9crit=C2=A0:
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> >   * trigger is when data words in MSC_TXFIFO is < 8.
> >   */
> >  #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > +	void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > +	void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > +	uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> >  };
>=20
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and=20
> is
> 30 lines shorter.
>=20
> I'm not terribly against either, so if nobody else bug on that, feel=20
> free
> to ignore my comment.

I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.

Cheers
James

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAlqjC00ACgkQbAtpk944
dnp5rw/+JdDz1OYUmiVyUElKgx994CGzHqb/PbX9+oitMmQR3RbUYNNaOEdZ2icn
lWLSobRUXvvleRjVHKJKNWZobiS7jyavTydtafaVhEOf5V40aph5iciHK1qX5k5c
ByTjmXDnFgCato6bQT/HrMIxCsZLlsTXqD9yANUnSGDb1Q1SifByXP3tzOfBNHHT
0hoCiYJAxU4NhnJvJ8eSfdFLyMcezPLb60RnMxD84JywVm3vHciANCFYiJRAjqfH
c8WnaIGb/0cL87a1zB9Pj7Mfif0A05c895+3FQRAZZjl4HzfOC35pzJVRBTade08
uHDBHz7MKhjAjX7+CRKC8y0xI+usurJ8VKeHZ40Dpn/ET3VBdBqlp5JkaK5Am2p6
3tOaUevG+b0zEJLZqxecF/s1oU6XgHo/cyA6KFDUkEUKLBSC7r/npybQvZVmjtAT
WORFJNynswSVqONd89gW7+3Pc8tFVGsSbWpNkrUq57WajahK5JEwE63FbvZR1F1q
soJlmPlK+UDYXDiiMy1tfOvx+SRbR0XnHfm4HYDeo0VLO1MB8W+JnjcUGVzG07T3
a0wwNcHmdnZrgBHr0a3Zmadt8lU6OAgkGtdsvyrq4+OZ/t9447tX3bIXvcH5w1yf
38Xd7nOVop0C8QQs/bpYyjN8Oll9RbgHyq4kkK3y4f7FaEbT3b4=
=Jx9X
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=+r2U=YT=lists.infradead.org=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 002B1CA9EB9
	for <linux-mediatek@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:48 +0000 (UTC)
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id C4D9D20679
	for <linux-mediatek@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:48 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qh87lG+T";
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hi2r2tM6"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4D9D20679
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=bombadil.20170209; h=Sender:
	Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:
	List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:
	Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	List-Owner; bh=W5WAdqB84tVEn0MJWIhkZRuPITIyrm7f480eSDsPKLI=; b=qh87lG+Tee5JIf
	L57V3KpzK64xNTPVCYbQTbixLGHlX06h7oqTGiT5lMGC8Ucane8Vi6k38XFJLsC41d9FtFmShXoCS
	yw3PtPtrgN1rcrezf0FOtvgPFTCxsR9XmeahBfoyHz/2zJ9aoJN0fDz0U8WuzdEUQcQsYfM0kLw3f
	oMbH7cBDTBpETgvCvA5Yjp8EXrWrSr++Ay4fx2B9rmVbVZdJxo52I9tUUJ6n9x5gaHmURGaYRibg0
	qYO0esbwr5yWwfKJ5VlHMRgrig+LAi0WeCNSbszw3DA4cYWuiQRy1eJwFJIx5ZYtcowlgqDxRjB3a
	OPcc3Yh1YW7H0H55UqLw==;
Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org)
	by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux))
	id 1iORll-000177-H9; Sat, 26 Oct 2019 19:30:37 +0000
Received: from mail.kernel.org ([198.145.29.99])
 by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux))
 id 1iORlW-0000zL-Ra; Sat, 26 Oct 2019 19:30:24 +0000
Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl
 [83.86.89.107])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 9081D20863;
 Sat, 26 Oct 2019 19:30:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1572118221;
 bh=1vWJNlJ9nmxdq2/TYTJ8H4g9od0RudmBwjhdidF/U3A=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=Hi2r2tM6TywiRAJPIiqblSIrVQlGBlYTNlHn/wq31sE5yhsBzHjW7cjrmAnMCq5AX
 amDA7DsHIXtCXm0xWGwyuIDNV/ta6Tivu3T9wVbhYe7ou371SsYBOGPq0tR7qgzHM6
 paQ0mVgIjrcv6ecZPQNeoZaEYDzKQRQIoq55wABA=
Date: Sat, 26 Oct 2019 21:30:18 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Frank Wunderlich <frank-w@public-files.de>
Subject: Re: your mail
Message-ID: <20191026193018.GA812200@kroah.com>
References: <20191026192359.27687-1-frank-w@public-files.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20191026192359.27687-1-frank-w@public-files.de>
User-Agent: Mutt/1.12.2 (2019-09-21)
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20191026_123022_925685_3D657AAC 
X-CRM114-Status: UNSURE (   6.24  )
X-CRM114-Notice: Please train this message.
X-BeenThere: linux-mediatek@lists.infradead.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <linux-mediatek.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mediatek>, 
 <mailto:linux-mediatek-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mediatek/>
List-Post: <mailto:linux-mediatek@lists.infradead.org>
List-Help: <mailto:linux-mediatek-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mediatek>, 
 <mailto:linux-mediatek-request@lists.infradead.org?subject=subscribe>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
 linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
 linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Linux-mediatek" <linux-mediatek-bounces@lists.infradead.org>
Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org

On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one

Odd email with no subject line :(

Plaese fix up and resend.

thanks,

greg k-h-

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ged Haywood <ged@www2.jubileegroup.co.uk>
Subject: Re: your mail
Date: Fri, 4 Jul 2003 19:21:39 +0100 (BST)
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.21.0307041919030.27519-100000@www2.jubileegroup.co.uk>
References: <20030704181015.76823.qmail@web13902.mail.yahoo.com>
Mime-Version: 1.0
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <20030704181015.76823.qmail@web13902.mail.yahoo.com>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Darryl Perry <dperry.geo@yahoo.com>
Cc: linux-msdos@vger.kernel.org

Hi there,

On Fri, 4 Jul 2003, Darryl Perry wrote:

> Does anybody have an hdimage file with MSDOS6.x
> installed that I can use?

Do be careful.  That sounds like abuse of copyright to me.

> I'd make it myself, but I don't have a floppy drive on my linux box.

Installing a floppy drive is a lot cheaper than defending a lawsuit...

73,
Ged.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Hartley <xjimh@worldnet.att.net>
Subject: Re: your mail
Date: Sat, 05 Jul 2003 09:48:31 -0500
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <3F06E53F.10703@worldnet.att.net>
References: <Pine.LNX.4.21.0307041919030.27519-100000@www2.jubileegroup.co.uk>
Reply-To: linuxjim@programmer.net
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.21.0307041919030.27519-100000@www2.jubileegroup.co.uk>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
To: linux-msdos@vger.kernel.org

If he owns a legal copy of the product (he says he'd do it himself if he 
had a floppy drive on the machine), one would have to be nitpicking in 
the extreme to call this a violation. He COULD send his copy to someone 
who would build the hdimage and send it back to him, that would be 
legal, wouldn't it? (IANAL) Getting someone who owns an identical copy 
of the DOS to send him the image without all the bother really doesn't 
sound any worse.

In any case, who is going to bother about suing one individual over a 
copy of **DOS** in this day and age? Most people have forgotten what DOS 
is by now! If he was doing a few thousand copies it might be a problem, 
but I think this one is WAY, WAY under the radar.

Jim Hartley

Ged Haywood wrote:

>Hi there,
>
>On Fri, 4 Jul 2003, Darryl Perry wrote:
>
>  
>
>>Does anybody have an hdimage file with MSDOS6.x
>>installed that I can use?
>>    
>>
>
>Do be careful.  That sounds like abuse of copyright to me.
>
>  
>
>>I'd make it myself, but I don't have a floppy drive on my linux box.
>>    
>>
>
>Installing a floppy drive is a lot cheaper than defending a lawsuit...
>
>73,
>Ged.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ged Haywood <ged@www2.jubileegroup.co.uk>
Subject: Re: your mail
Date: Sat, 5 Jul 2003 15:53:12 +0100 (BST)
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.21.0307051546120.2218-100000@www2.jubileegroup.co.uk>
References: <3F06E53F.10703@worldnet.att.net>
Mime-Version: 1.0
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <3F06E53F.10703@worldnet.att.net>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linuxjim@programmer.net
Cc: linux-msdos@vger.kernel.org

Hi there,

On Sat, 5 Jul 2003, Jim Hartley wrote:

> I think this one is WAY, WAY under the radar.

I'd agree if this weren't a public mailing list.

I'm more concerned with the reputation of the list.  If it earns a
reputation as a place for swapping pirate copies of software, that
might not be a Good Thing.

There has to be a way for the guy to get what he wants done without
broadcasting a technical infringement of a copyright owned by a ten
billion dollar potential adversary.

73,
Ged.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Hartley <xjimh@worldnet.att.net>
Subject: Re: your mail
Date: Sat, 05 Jul 2003 23:06:16 -0500
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <3F07A038.8080608@worldnet.att.net>
References: <Pine.LNX.4.21.0307051546120.2218-100000@www2.jubileegroup.co.uk> <1057435822.2023.49.camel@tamriel.terranforge.com>
Reply-To: linuxjim@programmer.net
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <1057435822.2023.49.camel@tamriel.terranforge.com>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
To: linux-msdos@vger.kernel.org

DOS 7.10? I guess that's one of those "M$-hidden-under-Windoze-DOS" 
versions? It gets confusing, since M$ used 7.x for those, while there is 
also an IBM PC-DOS 7.0 which is a "real" DOS and that's the one I always 
think of when DOS 7 is mentioned. That one is my favorite, I still have 
copies around, especially in the form of quick-boot utility diskettes. I 
guess one reason I like it is because I got it LEGALLY for free - a 
reward for participating in the Beta test. (Then again, those who know 
me know I will go to great lengths to avoid using ANY Micro$quish products.)

Jim Hartley

Lyvim Xaphir wrote:

>I agree with Jim Hartley.  This is pretty much a nonissue.  Dos isn't
>even supported by M$ any more as far as I know, and I've never heard of
>any case where M$ has gone after an individual for such a thing in the
>past anyway.  Their only concern are large scale pirates selling on the
>black market or corporations doing *current* release software on a
>significant basis.  They pretty much leave the individuals alone.
>
>And I don't think anyone will ever mistake this place as a site for
>swapping of illegal software.  This isn't anywhere near that class and
>to suggest that it might be is kind of edging over into the pinhead
>arena.
>
>On another note, if I was going to share a copy of Dos it would be
>version 7.10 because of it's superior memory management and stability. 
>7.10 was partially a response in 98 to gamer's claims of
>incompatibilities in winblows with some of the more sophisticated Dos
>games like Elder Scrolls Arena, Duke Nukem 3d and others.  It was the
>last best version of Dos.
>
>
>On Sat, 2003-07-05 at 10:53, Ged Haywood wrote:
>  
>
>>Hi there,
>>
>>On Sat, 5 Jul 2003, Jim Hartley wrote:
>>
>>    
>>
>>>I think this one is WAY, WAY under the radar.
>>>      
>>>
>>I'd agree if this weren't a public mailing list.
>>
>>I'm more concerned with the reputation of the list.  If it earns a
>>reputation as a place for swapping pirate copies of software, that
>>might not be a Good Thing.
>>
>>There has to be a way for the guy to get what he wants done without
>>broadcasting a technical infringement of a copyright owned by a ten
>>billion dollar potential adversary.
>>
>>73,
>>Ged.
>>    
>>
>
>--LX
>
>  
>


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jochen Reinwand <jbr.1@gmx.net>
Subject: Re: your mail
Date: Sun, 6 Jul 2003 13:20:01 +0200
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <200307061320.01503.jbr.1@gmx.net>
References: <Pine.LNX.4.21.0307051546120.2218-100000@www2.jubileegroup.co.uk> <1057435822.2023.49.camel@tamriel.terranforge.com> <3F07A038.8080608@worldnet.att.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <3F07A038.8080608@worldnet.att.net>
Content-Disposition: inline
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: linux-msdos@vger.kernel.org

The latest and best MS-DOS is as far as I know the DOS included in Windoze 
98SE. The One from ME is much smaller and misses a lot of tools. Although it 
is really there, no matter what M$ says...

I once installed 98SE and stripped of all Windows parts. After a few very easy 
tricks (e.g. add/change some lines to/in msdos.sys) you have a really good 
MS-DOS. VFAT is really important with today's harddrives...

Perhaps it would be a good idea to build an MS-DOS distribution with that 
version. Don't get it wrong! I'm not talking about illegal copies. It should 
be possible to write scripts that extract the necessary files from a 98SE CD, 
build ZIPs out of them, make a boot cd using the ERD (Emergency Rescue Disk) 
and so on. So everyone owning a legal 98SE copy can make his/her own _legal_ 
MS-DOS distribution with the help of free tools and scripts.
Then it would be nice to provide additional support for free tools and djgpp. 
Everything on one cd and a real cool Unix compatible MS-DOS is ready ;-)

Anybody interested in such an distribution?

Jochen

On Sunday 06 July 2003 06:06, Jim Hartley wrote:
> DOS 7.10? I guess that's one of those "M$-hidden-under-Windoze-DOS"
> versions? It gets confusing, since M$ used 7.x for those, while there is
> also an IBM PC-DOS 7.0 which is a "real" DOS and that's the one I always
> think of when DOS 7 is mentioned. That one is my favorite, I still have
> copies around, especially in the form of quick-boot utility diskettes. I
> guess one reason I like it is because I got it LEGALLY for free - a
> reward for participating in the Beta test. (Then again, those who know
> me know I will go to great lengths to avoid using ANY Micro$quish
> products.)
>
> Jim Hartley


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ged Haywood <ged@www2.jubileegroup.co.uk>
Subject: Re: your mail
Date: Sun, 6 Jul 2003 12:56:13 +0100 (BST)
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.21.0307061245060.12893-100000@www2.jubileegroup.co.uk>
References: <200307061320.01503.jbr.1@gmx.net>
Mime-Version: 1.0
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <200307061320.01503.jbr.1@gmx.net>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Jochen Reinwand <jbr.1@gmx.net>
Cc: linux-msdos@vger.kernel.org

Hi theere,

On Sun, 6 Jul 2003, Jochen Reinwand wrote:

> The latest and best MS-DOS is as far as I know the DOS included in Windoze 
> 98SE. The One from ME is much smaller and misses a lot of tools. Although it 
> is really there, no matter what M$ says...

I have an app for my business that's been running under DOS for about
20 years.  I'm (still) working on porting it to Linux because it's
getting close to the point where MSDOS6.22 won't be able to cope with
the size of disc partitions I'm going to need.  I've tried using the
W98 DOS to run this app, but it failed miserably every time and I
don't know why.  I haven't spent much time looking for the reasons but
it looks like the memory management - there are several versions of
EMM386.SYS and HIMEM.SYS with are supplied with the various flavours
of DOS and I haven't worked out what combinations are OK and what not.

Are you saying that the W98 DOS will allow me to use bigger discs?
If so then I'm very interested indeed.  My understanding is that even
with the W98 VFAT you can still only go up to about 8G, is that right?
It would be nice to know - although it's OK for my app, I'll be long
dead before we use that much for our product file... :(

> I once installed 98SE and stripped of all Windows parts. After a few very easy 
> tricks (e.g. add/change some lines to/in msdos.sys)

Tell us more!

> Perhaps it would be a good idea to build an MS-DOS distribution with that 
> version. Don't get it wrong! I'm not talking about illegal copies. [snip]
> 
> Anybody interested in such an distribution?

Very much so.  It could give me a breathing space I think I might need.

73,
Ged.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jochen Reinwand <jbr.1@gmx.net>
Subject: Re: your mail
Date: Sun, 6 Jul 2003 18:26:18 +0200
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <200307061826.18315.jbr.1@gmx.net>
References: <Pine.LNX.4.21.0307061245060.12893-100000@www2.jubileegroup.co.uk>
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_q2EC/3Ag/PDtOEO"
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.21.0307061245060.12893-100000@www2.jubileegroup.co.uk>
List-Id: <linux-msdos.vger.kernel.org>
To: linux-msdos@vger.kernel.org


--Boundary-00=_q2EC/3Ag/PDtOEO
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi!

> I have an app for my business that's been running under DOS for about
> 20 years.  I'm (still) working on porting it to Linux because it's
> getting close to the point where MSDOS6.22 won't be able to cope with
> the size of disc partitions I'm going to need.  I've tried using the
> W98 DOS to run this app, but it failed miserably every time and I
> don't know why.  I haven't spent much time looking for the reasons but
> it looks like the memory management - there are several versions of
> EMM386.SYS and HIMEM.SYS with are supplied with the various flavours
> of DOS and I haven't worked out what combinations are OK and what not.

There are a few problems, when using a "Windows-DOS" like a normal MS-DOS. The 
first problem is MSDOS.SYS (see below). Another Problem that took me a long 
time to figure out were the new commands in CONFIG.SYS. E.g. you should 
normale use the following setting for "DOS":
DOS=HIGH,UMB,NOAUTO

HIGH and UMB are well known, but NOAUTO is VERY important. If it is not 
present, Windows/DOS will load drivers if you don't load them. So if no line 
like
device=C:\MSDOS\himem.sys
is present, himem.sys will be loaded automatically with the parameters Windows 
thinks are good for you!
Another example: A lot of old programs have problems, when emm386.exe is 
loaded. So you comment out the line in config.sys, reboot and... EMM386 is 
once again loaded and your program is still not working. So you should set 
NOAUTO and after disabling EMM386 in CONFIG.SYS it is _really_ disabled.

I found a lot of info about the boot process and other interesting things 
about "Windows-DOS". But a lot of it is in German and only on paper. So the 
information has to be digitized and translated. Or you can search for more 
info on the net. Btw: Has M$ really deleted all DOS info from there web 
pages? I found a lot of interesting stuff there...
Would be useful to include it in a distribution...

> Are you saying that the W98 DOS will allow me to use bigger discs?
> If so then I'm very interested indeed.  My understanding is that even
> with the W98 VFAT you can still only go up to about 8G, is that right?

No. The 8GB limit is a hardware/BIOS problem.
On my system:

# fdisk -l /dev/hde
(...)
/dev/hde7           639      5005  35077896    b  Win95 FAT32
(...)

35GB FAT32 formated and now problems under Windows, Linux or MS-DOS (7.x)!

> > I once installed 98SE and stripped of all Windows parts. After a few very
> > easy tricks (e.g. add/change some lines to/in msdos.sys)
>
> Tell us more!

MSDOS.SYS controls the start of Windows. You can even change it to an extend 
that Windows isn't loaded at all!
I changed for example:

In the [Paths] section:

;WinDir=C:\WINDOWS
;WinBootDir=C:\WINDOWS
WinDir=C:\MSDOS
WinBootDir=C:\MSDOS

If it is MS-DOS it should have it's own place ;-)

More important:

[Options]
BootMulti=1    ; Make it possible to start DOS
BootGUI=0      ; Don't start Windows, only MS-DOS. Now you don't need any 
               ; Windows files at all
Logo=0         ; Don't display this silly Windows logo!
AutoScan=1     ; Can't remember what that option is good for...

I attached a text I found about MSDOS.SYS. I don't know where...

> > Perhaps it would be a good idea to build an MS-DOS distribution with that
> > version. Don't get it wrong! I'm not talking about illegal copies. [snip]
> >
> > Anybody interested in such an distribution?
>
> Very much so.  It could give me a breathing space I think I might need.

I started this "project" a long time ago and made a GREAT mistake. I tried to 
build up a C:\MSDOS directory containing everything I found useful for a DOS 
distribution. Now I don't know where all these files came from. So it will 
get hard to figure it out again.
Another problem is that I have a German version of Windows. Even filenames 
differ between the different international version. I doubt that you will 
find files like allgem.txt and antwort.txt in an English version of 
Windows...

Nevertheless it would be possible to make this distribution. But there are a 
lot of things that have to be figured out. A basic problem: Do we use a 
Windows/DOS or a Linux/Unix system for extracting the files from Windows and 
for building the new system.
The following functions need further inspection:

What boot system to use? Booting from a Windows CD is possible, but building a 
new bootable CD is better. The ERD could be used.
If we only have Linux how can we build this ERD. The necessary file are 
installed with Windows in the directory EBD and should be somewhere in the 
CAB files on the Windows CD. Copy them to disk is easy, but how to do a "sys 
a:" from within Linux?
Or is it possible to extract the boot image from the Windows CD?

Can we access CAB files from within Linux at all? I have not searched for a 
tool by now...

The greatest problem: If you make a build system running under DOS or DOS 
compatible Windows: You can only use it, if you already have a DOS compatible 
system! Normally someone wants such a distribution builder, if he/she only 
has a Unix or DOS incompatible Windows system.
And don't forget: Linux is much more powerful in doing scripting tasks ;-)

Comments welcome. Especially if someone has an idea how all this could be done 
really easy...

Jochen

--Boundary-00=_q2EC/3Ag/PDtOEO
Content-Type: text/plain; charset="iso-8859-1"; name="msdossys.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="msdossys.txt"

MSDOS.SYS: Special Startup Values

Windows 95 Setup creates a hidden, read-only system file named MSDOS.SYS in
the root of the computer's boot drive. This file contains important paths u=
sed
to locate other Windows files, including the Registry. MSDOS.SYS also suppo=
rts
an [Options] section, which you can add to tailor the startup process.

The following example shows a typical file with default values:

---------------------------------------------------------------------------=
---
[Options]
BootGUI=3D1

[Paths]
WinDir=3DC:\WINDOWS
WinBootDir=3DC:\WINDOWS
HostWinBootDrv=3DC
---------------------------------------------------------------------------=
---

Most values in the [Options] section are Boolean  that is, the value can be=
 1
(enabled) or 0 (disabled). The following table describes entries in MSDOS.S=
YS,
using the typical default values.



MSDOS.SYS Values


Entry               Description


[Paths] section:

HostWinBootDrv=3Dc    Defines the location of the boot drive root directory.
WinBootDir=3D         Defines the location of the necessary startup files. =
The
                    default is the directory specified during Setup;
                    for example, C:\WINDOWS.
WinDir=3D             Defines the location of the Windows 95 directory as
                    specified during Setup.

[Options] section:

BootDelay=3Dn         Sets the initial startup delay to n seconds. The defa=
ult
                    is 2. BootKeys=3D0 disables the delay. The only purpose=
 of
                    the delay is to give the user sufficient time to press =
F8
                    after the Starting Windows message appears.
BootFailSafe=3D       Enables Safe Mode for system startup. The default is =
0.
                    (This setting is enabled typically by equipment
                    manufacturers for installation.)
BootGUI=3D            Enables automatic graphical startup into Windows 95. =
The
                    default is 1.
BootKeys=3D           Enables the startup option keys (that is, F5, F6, and=
 F8).
                    The default is 1. Setting this value to 0 overrides the
                    value of BootDelay=3Dn and prevents any startup keys fr=
om
                    functioning. This setting allows system administrators =
to
                    configure more secure systems. (These startup keys are
                    described in Chapter 35, "General Troubleshooting.")
BootMenu=3D           Enables automatic display of the Windows 95 Startup m=
enu,
                    so that the user must press F8 to see the menu. The
                    default is 0. Setting this value to 1 eliminates the ne=
ed
                    to press F8 to see the menu.
BootMenuDefault=3D#   Sets the default menu item on the Windows Startup men=
u;
                    the default is 3 for a computer with no networking
                    components, and 4 for a networked computer.
BootMenuDelay=3D#     Sets the number of seconds to display the Windows Sta=
rtup
                    menu before running the default menu item. The default =
is
                    30.
BootMulti=3D          Enables dual-boot capabilities. The default is 0. Set=
ting
                    this value to 1 enables the ability to start MS-DOS by
                    pressing F4 or by pressing F8 to use the Windows Startup
                    menu.
BootWarn=3D           Enables the Safe Mode startup warning. The default is=
 1.
BootWin=3D            Enables Windows 95 as the default operating system.
                    Setting this value to 0 disables Windows 95 as the
                    default; this is useful only with MS-DOS version 5 or 6=
.x
                    on the computer. The default is 1.
DblSpace=3D           Enables automatic loading of DBLSPACE.BIN.
                    The default is 1.
DoubleBuffer=3D       Enables loading of a double-buffering driver for a SC=
SI
                    controller. The default is 0. Setting this value to 1
                    enables double-buffering, if required by the SCSI
                    controller.
DrvSpace=3D           Enables automatic loading of DRVSPACE.BIN.
                    The default is 1.
LoadTop=3D            Enables loading of COMMAND.COM or DRVSPACE.BIN at the=
 top
                    of 640K memory. The default is 1. Set this value to 0 w=
ith
                    Novell=AE NetWare=AE or any software that makes assumpt=
ions
                    about what is used in specific memory areas.
Logo=3D               Enables display of the animated logo. The default is =
1.
                    Setting this value to 0 also avoids hooking a variety of
                    interrupts that can create incompatibilities with certa=
in
                    memory managers from other vendors.
Network=3D            Enables Safe Mode With Networking as a menu option. T=
he
                    default is 1 for computers with networking installed. T=
his
                    value should be 0 if network software components are not
                    installed.



Tip for Starting an Earlier Version of MS-DOS
If you installed Windows 95 in its own directory, the earlier version of
MS-DOS is preserved on your hard disk. If you set BootMulti=3D1 in the [Opt=
ions]
section in the Windows 95 version of MSDOS.SYS, you can start the earlier
version of MS-DOS by pressing F4 when the Starting Windows message appears
during system startup.

--Boundary-00=_q2EC/3Ag/PDtOEO--


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eemeli Kantola <ekantola@welho.com>
Subject: Re: your mail
Date: Sun, 06 Jul 2003 22:03:26 +0300
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <3F08727E.4000209@welho.com>
References: <Pine.LNX.4.21.0307061245060.12893-100000@www2.jubileegroup.co.uk> <200307061826.18315.jbr.1@gmx.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <200307061826.18315.jbr.1@gmx.net>
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
To: linux-msdos@vger.kernel.org

Jochen Reinwand wrote:

> AutoScan=1     ; Can't remember what that option is good for...

If I remember correctly, that is used by Windows only to automatically 
scan disks at startup after a system crash or something. Not needed for 
plain dos.

> Nevertheless it would be possible to make this distribution. But there are a 
> lot of things that have to be figured out. A basic problem: Do we use a 
> Windows/DOS or a Linux/Unix system for extracting the files from Windows and 
> for building the new system.
> The following functions need further inspection:
> 
> What boot system to use? Booting from a Windows CD is possible, but building a 
> new bootable CD is better. The ERD could be used.
> If we only have Linux how can we build this ERD. The necessary file are 
> installed with Windows in the directory EBD and should be somewhere in the 
> CAB files on the Windows CD. Copy them to disk is easy, but how to do a "sys 
> a:" from within Linux?

Well, I booted Dos 7 (from 98se) on my hard drive with Dosemu 1.1.5 as 
root and executed "sys c: a:". And the resulting boot disk works! You 
will need a working Dos installed, though. Or at least a boot floppy.

> Can we access CAB files from within Linux at all? I have not searched for a 
> tool by now...

You can extract cabs with extract.exe (from windir\command, or it can be 
found on the windows install cd, too). Seems to work perfectly with both 
Dosemu and Wine under Linux.


-Eemeli


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jochen Reinwand <jbr.1@gmx.net>
Subject: Re: your mail
Date: Mon, 7 Jul 2003 01:10:59 +0200
Sender: linux-msdos-owner@vger.kernel.org
Message-ID: <200307070110.59986.jbr.1@gmx.net>
References: <Pine.LNX.4.21.0307061245060.12893-100000@www2.jubileegroup.co.uk> <200307061826.18315.jbr.1@gmx.net> <3F08727E.4000209@welho.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-msdos-owner@vger.kernel.org>
In-Reply-To: <3F08727E.4000209@welho.com>
Content-Disposition: inline
List-Id: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: linux-msdos@vger.kernel.org

> > Nevertheless it would be possible to make this distribution. But there
> > are a lot of things that have to be figured out. A basic problem: Do we
> > use a Windows/DOS or a Linux/Unix system for extracting the files from
> > Windows and for building the new system.
> > The following functions need further inspection:
> >
> > What boot system to use? Booting from a Windows CD is possible, but
> > building a new bootable CD is better. The ERD could be used.
> > If we only have Linux how can we build this ERD. The necessary file are
> > installed with Windows in the directory EBD and should be somewhere in
> > the CAB files on the Windows CD. Copy them to disk is easy, but how to do
> > a "sys a:" from within Linux?
>
> Well, I booted Dos 7 (from 98se) on my hard drive with Dosemu 1.1.5 as
> root and executed "sys c: a:". And the resulting boot disk works! You
> will need a working Dos installed, though. Or at least a boot floppy.

Nice idea! Perhaps it is possible to execute MS-DOS "sys" with some tricks 
without installing a complete 98SE...
It would be nice to have small a Linux prog to do the same, but booting the 
Win98SE cd with dosemu would be a solution if this cannot be done.
Seems to be the only real problem I face in this project......

I believe I found it! On the win98se cd I found in tools/mtsutil/fat32ebd/ the 
MS-DOS tool that does exactly what I want to do without using "sys". Seems 
like image.dsk "formats" and "sys's" a floppy be simply doing a
cat image.dsk > /dev/fd0
I will reboot and test it after sending this mail ;-)

> > Can we access CAB files from within Linux at all? I have not searched for
> > a tool by now...
>
> You can extract cabs with extract.exe (from windir\command, or it can be
> found on the windows install cd, too). Seems to work perfectly with both
> Dosemu and Wine under Linux.

I found a really cool Linux tool called cabextract 
(http://www.kyz.uklinux.net/cabextract.php3). I can extract the complete 
Win98SE CABs from cd! But that's also the problem. I can only extract 
everything. I wrote an e-mail to the author requesting a possibility to 
specify the files to be extracted.

Jochen


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-next-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 2A7B4C7EE2D
	for <linux-next@archiver.kernel.org>; Thu, 25 May 2023 12:04:10 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S234284AbjEYMEJ (ORCPT <rfc822;linux-next@archiver.kernel.org>);
        Thu, 25 May 2023 08:04:09 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44866 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S240892AbjEYMEH (ORCPT
        <rfc822;linux-next@vger.kernel.org>); Thu, 25 May 2023 08:04:07 -0400
Received: from verein.lst.de (verein.lst.de [213.95.11.211])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B40C12E;
        Thu, 25 May 2023 05:04:06 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407)
        id 244AA68AFE; Thu, 25 May 2023 14:04:03 +0200 (CEST)
Date:   Thu, 25 May 2023 14:04:02 +0200
From:   Christoph Hellwig <hch@lst.de>
To:     Murphy Zhou <jencce.kernel@gmail.com>
Cc:     Linux-Next <linux-next@vger.kernel.org>,
        linux-xfs <linux-xfs@vger.kernel.org>,
        Christoph Hellwig <hch@lst.de>, akpm@linux-foundation.org
Subject: Re: your mail
Message-ID: <20230525120402.GA6281@lst.de>
References: <CADJHv_ujo+QUE7f420t4XACGw4RvVpckKSJcJ_9_Z0b2gdmr+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADJHv_ujo+QUE7f420t4XACGw4RvVpckKSJcJ_9_Z0b2gdmr+g@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Precedence: bulk
List-ID: <linux-next.vger.kernel.org>
X-Mailing-List: linux-next@vger.kernel.org

On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> Hi Christoph,
> 
> The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> starts to fail on xfs, not on other fs. It was pass on the previous
> tag next-20230519.
> 
> After those 2 commits reverted on the top of 0522 tree, it passed.
> 
>     iomap: update ki_pos in iomap_file_buffered_write
>     iomap: assign current->backing_dev_info in iomap_file_buffered_write
> 
> (the second one was reverted because the first one depends on it)

Yes, they are known broken.  There has been a v2 on the list already,
which still has issues for fuse, so there will be a v3.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-next-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 000ABC7EE2D
	for <linux-next@archiver.kernel.org>; Thu, 25 May 2023 12:45:46 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S231895AbjEYMpp (ORCPT <rfc822;linux-next@archiver.kernel.org>);
        Thu, 25 May 2023 08:45:45 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34656 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S239813AbjEYMpb (ORCPT
        <rfc822;linux-next@vger.kernel.org>); Thu, 25 May 2023 08:45:31 -0400
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 649E49B;
        Thu, 25 May 2023 05:45:30 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-b9daef8681fso421114276.1;
        Thu, 25 May 2023 05:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20221208; t=1685018729; x=1687610729;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=n2EgvRCmk8HZRlkVe8tT7FrQyjXG54U7wK2DUs1qcNc=;
        b=b23Z3Orjg0Q3D4S0JZ9BrlYAhLoBpRnvT6ryr0cpcHviF9l3HreHLzfDNqRkM5RAe9
         +ObZge3mEjxjUXGOdGLuHLDhRlN1HntNmWZFEUaUGCG3lY7qsif3d52s0T0DUOB/knk/
         oMQ87f1+uypP5JgksMGV7HbkLankLBrsS3Dk52r9VBwCMwgeeF198gvTIK6GMGuEIOEf
         rIXQkeEbiwuR4/g1ATr22+X2W10YGbV2TMOVLC9XHNT8syg1JhjrFbT3QWfHHzriRMW/
         cxF+dUyuG4rDIS+EQTrFTtT8MqqVKuGhq/DP4QkxWwf7zFMltlpDmEHSpdMIdOJXSGqb
         YNVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1685018729; x=1687610729;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=n2EgvRCmk8HZRlkVe8tT7FrQyjXG54U7wK2DUs1qcNc=;
        b=IQ8G9FVufwviavsRaFdKqNpKeNT0LsIRiUTmfdNkF4e/N2MKTP0GZe1g93lVT5Tjh0
         hOG4q+7eD/mV02ZmGLCdM4X3p//8gVOx13MsIhLNTHjVG7w82MN5oT7+jn+XqVsqLPWv
         7+ieZ0SfG+/mnh43B2DqrYAIdF1V1RMhNoR5bPpAxEGHT7SKusl05jQH4SuhWvSbLldI
         MgczbFRWomQAwzZvnYQkv5tjZbW5LG90Rckat8kpjMYtn3t9mEt7ad/GxGvxId959oh5
         pFrgnzgnkqJ8EFVRjvDWW2ITfKUOzymBymcKQ2fkYOCLDg3xD/Dr2hl2vfbXMYAlyA8Y
         Uy3Q==
X-Gm-Message-State: AC+VfDxqEbs8RLfff9sf9ZxPZ4W8o5wj7oUcKKO4Ltgocxfi3EaXtwUC
        chxbrNZOmhLGsTgVKuNrr19BdY7/j8XZTcL7321NIqiXYSc=
X-Google-Smtp-Source: ACHHUZ6q+zm+eX5tov55de23ywRnl2eTWPeT6sRnqICONAy/ywfn/3+IVWHMnoT5yYdrmtVEFkmAyyfdZd9LLFjS5T4=
X-Received: by 2002:a0d:cc81:0:b0:561:b783:fb76 with SMTP id
 o123-20020a0dcc81000000b00561b783fb76mr20669529ywd.51.1685018729593; Thu, 25
 May 2023 05:45:29 -0700 (PDT)
MIME-Version: 1.0
References: <CADJHv_ujo+QUE7f420t4XACGw4RvVpckKSJcJ_9_Z0b2gdmr+g@mail.gmail.com>
 <20230525120402.GA6281@lst.de>
In-Reply-To: <20230525120402.GA6281@lst.de>
From:   Murphy Zhou <jencce.kernel@gmail.com>
Date:   Thu, 25 May 2023 20:45:18 +0800
Message-ID: <CADJHv_u7pV_g5DeNBjQKPXv4tfSg6Rc9FXjKD5F+ioHX6jrVdg@mail.gmail.com>
Subject: Re: your mail
To:     Christoph Hellwig <hch@lst.de>
Cc:     Linux-Next <linux-next@vger.kernel.org>,
        linux-xfs <linux-xfs@vger.kernel.org>, akpm@linux-foundation.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
List-ID: <linux-next.vger.kernel.org>
X-Mailing-List: linux-next@vger.kernel.org

On Thu, May 25, 2023 at 8:04=E2=80=AFPM Christoph Hellwig <hch@lst.de> wrot=
e:
>
> On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> > Hi Christoph,
> >
> > The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> > starts to fail on xfs, not on other fs. It was pass on the previous
> > tag next-20230519.
> >
> > After those 2 commits reverted on the top of 0522 tree, it passed.
> >
> >     iomap: update ki_pos in iomap_file_buffered_write
> >     iomap: assign current->backing_dev_info in iomap_file_buffered_writ=
e
> >
> > (the second one was reverted because the first one depends on it)
>
> Yes, they are known broken.  There has been a v2 on the list already,
> which still has issues for fuse, so there will be a v3.

Great! Thank you.
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <owner-mtd@imladris.demon.co.uk>
Received: from 24.64.25.86.ab.wave.home.com
	([24.64.25.86] helo=white.priv.deltatee.com ident=mail)
	by imladris.mvhi.com with esmtp (Exim 2.12 #1)
	id 112N3E-0006j9-00
	for mtd@infradead.org; Thu, 8 Jul 1999 23:53:56 +0100
Date: Thu, 8 Jul 1999 16:53:49 -0600 (MDT)
From: Jason Gunthorpe <jgg@deltatee.com>
To: David Woodhouse <David.Woodhouse@mvhi.com>
cc: "D. Jeff Dionne / VE3DJF" <jeff@ampr.harc.on.ca>, mtd@infradead.org
Subject: Re: your mail
In-Reply-To: <E112KPc-0005ge-00@devel2.axiom.internal>
Message-ID: <Pine.LNX.3.96.990708165218.3773A-100000@white.priv.deltatee.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mtd@imladris.demon.co.uk
List-ID: <linux-mtd.lists.infradead.org>


On Thu, 8 Jul 1999, David Woodhouse wrote:

> > Anyway, having come over from the uClinux project, I am very
> > interested in anything you may have.  I can also lend a hand.  We've
> > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > (which as you know is read only). 

Can you fire over your patch to ROMfs to make it do this? The 2.2.10
kernel version doesn't. 
  
> We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is 
> something like this:

I have read only ffs2 running, but the hair brained compression scheme is
giving me pain :<

On lwn there was a pointer to a Hard Hat linux which also claimed flash
support with a flash file system, anyone know more about those guys?

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <owner-mtd@imladris.demon.co.uk>
Received: from [209.167.190.89] (helo=ampr.harc.on.ca)
	by imladris.mvhi.com with esmtp (Exim 2.12 #1)
	id 112Uoh-0006u4-00
	for mtd@infradead.org; Fri, 9 Jul 1999 08:11:27 +0100
From: "D. Jeff Dionne / VE3DJF" <jeff@ampr.harc.on.ca>
Message-Id: <199907090709.HAA04138@ampr.harc.on.ca>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.3.96.990708165218.3773A-100000@white.priv.deltatee.com> from Jason Gunthorpe at "Jul 8, 1999  4:53:49 pm"
To: jgg@deltatee.com (Jason Gunthorpe)
Date: Fri, 9 Jul 1999 07:09:48 +0000 (GMT)
Cc: mtd@infradead.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mtd@imladris.demon.co.uk
List-ID: <linux-mtd.lists.infradead.org>

> 
> On Thu, 8 Jul 1999, David Woodhouse wrote:
> 
> > > Anyway, having come over from the uClinux project, I am very
> > > interested in anything you may have.  I can also lend a hand.  We've
> > > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > > (which as you know is read only). 
> 
> Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> kernel version doesn't. 

Unfortunately, in it's current form it will not be of any use to you I suspect.
It's for 2.0.37, and is tied up with another meg of patch.  It touches lots
of stuff, and it needs cleaning :-(

We're also very 68k right now, so Linux/Intel would be some work.  You'll
need fully position independant code to start with... Does -fpic go far enough
on Intel?  You'll need to hack the ELF loader, we run a simple (low overhead)
binary format.

>   
> > We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is 
> > something like this:
> 
> I have read only ffs2 running, but the hair brained compression scheme is
> giving me pain :<
> 
> On lwn there was a pointer to a Hard Hat linux which also claimed flash
> support with a flash file system, anyone know more about those guys?
> 
> Jason
> 



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <owner-mtd@imladris.demon.co.uk>
Received: from 24.64.25.86.ab.wave.home.com
	([24.64.25.86] helo=white.priv.deltatee.com ident=mail)
	by imladris.mvhi.com with esmtp (Exim 2.12 #1)
	id 112cYq-00075o-00
	for mtd@infradead.org; Fri, 9 Jul 1999 16:27:36 +0100
Date: Fri, 9 Jul 1999 09:27:31 -0600 (MDT)
From: Jason Gunthorpe <jgg@deltatee.com>
To: "D. Jeff Dionne / VE3DJF" <jeff@ampr.harc.on.ca>
cc: mtd@infradead.org
Subject: Re: your mail
In-Reply-To: <199907090709.HAA04138@ampr.harc.on.ca>
Message-ID: <Pine.LNX.3.96.990709092452.8974B-100000@white.priv.deltatee.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mtd@imladris.demon.co.uk
List-ID: <linux-mtd.lists.infradead.org>



On Fri, 9 Jul 1999, D. Jeff Dionne / VE3DJF wrote: 

> > Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> > kernel version doesn't. 
> 
> Unfortunately, in it's current form it will not be of any use to you I suspect.
> It's for 2.0.37, and is tied up with another meg of patch.  It touches lots
> of stuff, and it needs cleaning :-(
> 
> We're also very 68k right now, so Linux/Intel would be some work.  You'll
> need fully position independant code to start with... Does -fpic go far enough
> on Intel?  You'll need to hack the ELF loader, we run a simple (low overhead)
> binary format.

Oh this is not at all what I was thinking, on Intel all we'd need to do is
setup the proper page tables so that each 4k page mapped to the correct 4k
chunk of flash, the FFS write unit size and alignment would be set to 4k
for executables. There should be no need to worry about pic and elf will
run fine like that too.
 
It should be really simple if someone can think up either a modification
to readpage() that adjusts the physical  location of the given page
structure or a new mmap that sets up a new page table mapping..

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from wohnheim.fh-wedel.de ([213.39.233.138])
	by pentafluge.infradead.org with esmtp (Exim 4.22 #5 (Red Hat Linux))
	id 19wlL8-0007XV-J1
	for <linux-mtd@lists.infradead.org>; Tue, 09 Sep 2003 17:27:38 +0100
Date: Tue, 9 Sep 2003 18:26:13 +0200
From: =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de>
To: J B <mad_flasher@hotmail.com>
Message-ID: <20030909162613.GA20679@wohnheim.fh-wedel.de>
References: <Law11-F24DVK3aXvlcq000025d9@hotmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Law11-F24DVK3aXvlcq000025d9@hotmail.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
cc: linux-mtd@lists.infradead.org
cc: jffs-dev@axis.com
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 9 September 2003 08:44:21 -0500, J B wrote:
> 
> A jffs2 internals question for the masses:
> 
> Besides the 128Kb max kmalloc issue, is there any restriction on the size 
> of an eraseblock that jffs2 can use?
> 
> I am using the slram driver with a 4Kb eraseblock size to create a 4Mb ram 
> device.  I mount jffs2 on top of this and everything appears to work until 
> the filesystem becomes full.  I try removing a file and the remove command 
> returns "rm: cannot unlink `foo' : No space left on device".  df reports 
> 100% usage.
> 
> Also, looking at the output from having CONFIG_JFFS2_FS_DEBUG=1, it appears 
> that garbage collection is constantly running and picking blocks from the 
> clean list because there are none on the dirty list.  Eventually even this 
> fails and the garbage collector loops and complains repeatedly:
> 
> "Argh. No free space left for GC.  nr_erasing_blocks is 0.  nr_free_blocks 
> is 0. (erasingempty: yes, erasependingempty: yes)
> jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28"
> 
> The thread_should_wake is returning 1 because the dirty size is > an 
> eraseblock, so it loops forever.
> 
> If I switch the eraseblock size in slram back to 64Kb, this problem does 
> not appear.  So again, are there any restricitons on how small of an 
> eraseblock size you can use, or is this something that hasn't ever really 
> been an issue?

Not completely unexpected.  I've always disliked the 5-eraseblock
number and started a discussion with David on the mtd list some time
ago.  For some reason, other matters occupied our minds so this was
unfinished.  But it is still in the archives.

The problem is that jffs2 doesn't need 5 eraseblocks, but rather 2 +
number_of_eraseblocks / some_constant.  So with 1024 eraseblocks, you
appear to need more than 5 (empirically proven :), while with 64
eraseblocks, you could get away with 5.  Maybe not, but there are very
few (no) bug reports, so it should be safe.

What jffs2 needs is to get rid of the constants for
JFFS2_RESERVED_BLOCKS_* and make them superblock variables instead.
Then we have to calculate them during mount time using some formula.
A patch doing the first step should still be in the archives, in the
same thread as the discussion or nearby.

Hope that helps!

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 16 Nov 2004 14:21:31 +0000 (GMT)
From: "Artem B. Bityuckiy" <dedekind@phoenix.infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <1100613327.8191.6954.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
References: <Pine.LNX.4.58.0411161316390.25950@phoenix.infradead.org>
	<1100613327.8191.6954.camel@hades.cambridge.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Artem Bityuckiy <dedekind@infradead.org>
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 13:48 +0000, Artem B. Bityuckiy wrote:
> > Hello David,
> > 
> > When I create checkpoints, I read all the nodes which will be referred by 
> > this checkpoint and check their CRCs. This is because we must trust 
> > checkpoints and do not check CRCs for them on the iget() call.
> > 
> > When the Garbage Collector moves node, which is currently referred by an 
> > checkpoint inact (I mean the jffs2_garbage_collect_pristine() function), 
> > we have to read this node after we GC it. This is the problem. The unclean 
> > reboot may happed and we can not guarantee that all noted in checkpoint 
> > are OK. :-(
> > 
> > So, how do you think is it absolutely necessary to check that nodes which 
> > are reffered by checkpoint are OK? Is it OK if we just detect errors when 
> > we actually read file?
> 
> No, that's not OK. We'd actually lose the data in that case, surely? We
> _need_ to pick up the new copy of the node, if the old one is absent.
> Either we have to obsolete the newer checkpoint or we have to ignore the
> checkpoint data if we get a failure, and rescan properly.
> 
> -- 
> dwmw2
> 
> 
:-((

Very bad...
This means that checkpoints will have short live-time. I mean, that if we 
have some read-only file and have generated the checkpoint for this file, 
we will need to rewrite the checkpoint periodically when it becomes 
obsolete because the file's nodes are moved by the GC.... :-(

I call checkpoint obsolete when:
1. The newer checkpoint exist (usual meaning)
2. More that N % of nodes, referred by the checkpoint are disappeared 
since were Garbage Collected.

I dreamed about checkpoints which we may write only once for constant 
files (for example, glibc libraries) ....

So, this problem is solvable I believe, but no I'm not quite sure are 
checkpoints will be so useful as I thought ... 

 -- Best 
Regards, Artem B. Bityuckiy,
St.-Petersburg, Russia.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Woodhouse <dwmw2@infradead.org>
To: "Artem B. Bityuckiy" <dedekind@infradead.org>
In-Reply-To: <Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
References: <Pine.LNX.4.58.0411161316390.25950@phoenix.infradead.org>
	<1100613327.8191.6954.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
Content-Type: text/plain
Message-Id: <1100615381.8191.6957.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
Date: Tue, 16 Nov 2004 14:29:41 +0000
Content-Transfer-Encoding: 7bit
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> I dreamed about checkpoints which we may write only once for constant 
> files (for example, glibc libraries) ....
> 
> So, this problem is solvable I believe, but no I'm not quite sure are 
> checkpoints will be so useful as I thought ... 

Hm. I was imagining that we'd read in the information from the
checkpoint, and then pull in anything _new_ -- which would include any
nodes which weren't included in the checkpoint.

-- 
dwmw2

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 16 Nov 2004 14:54:38 +0000 (GMT)
From: "Artem B. Bityuckiy" <dedekind@infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <1100615381.8191.6957.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.58.0411161450260.27293@phoenix.infradead.org>
References: <Pine.LNX.4.58.0411161316390.25950@phoenix.infradead.org>
	<1100613327.8191.6954.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
	<1100615381.8191.6957.camel@hades.cambridge.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Artem Bityuckiy <dedekind@infradead.org>
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> > I dreamed about checkpoints which we may write only once for constant 
> > files (for example, glibc libraries) ....
> > 
> > So, this problem is solvable I believe, but no I'm not quite sure are 
> > checkpoints will be so useful as I thought ... 
> 
> Hm. I was imagining that we'd read in the information from the
> checkpoint, and then pull in anything _new_ -- which would include any
> nodes which weren't included in the checkpoint.

Yes. But imagine some file which is constant and is never changed. We 
create checkpoint for it and this checkpoint covers all the nodes. So, we 
will need to rewrite new checkpoint even for this file when its nodes are 
garbage collected... 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Woodhouse <dwmw2@infradead.org>
To: "Artem B. Bityuckiy" <dedekind@infradead.org>
In-Reply-To: <Pine.LNX.4.58.0411161450260.27293@phoenix.infradead.org>
References: <Pine.LNX.4.58.0411161316390.25950@phoenix.infradead.org>
	<1100613327.8191.6954.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
	<1100615381.8191.6957.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161450260.27293@phoenix.infradead.org>
Content-Type: text/plain
Message-Id: <1100617420.8191.6959.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
Date: Tue, 16 Nov 2004 15:03:41 +0000
Content-Transfer-Encoding: 7bit
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> Yes. But imagine some file which is constant and is never changed. We 
> create checkpoint for it and this checkpoint covers all the nodes. So, we 
> will need to rewrite new checkpoint even for this file when its nodes are 
> garbage collected... 

Yeah. In particular we'd nee to rewrite a new checkpoint when the block
containing the old checkpoint was garbage-collected anyway.

-- 
dwmw2

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 16 Nov 2004 15:09:32 +0000 (GMT)
From: "Artem B. Bityuckiy" <dedekind@infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <1100617420.8191.6959.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.58.0411161507340.27293@phoenix.infradead.org>
References: <Pine.LNX.4.58.0411161316390.25950@phoenix.infradead.org>
	<1100613327.8191.6954.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161405080.27293@phoenix.infradead.org>
	<1100615381.8191.6957.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0411161450260.27293@phoenix.infradead.org>
	<1100617420.8191.6959.camel@hades.cambridge.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Artem Bityuckiy <dedekind@infradead.org>
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: your mail
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> > Yes. But imagine some file which is constant and is never changed. We 
> > create checkpoint for it and this checkpoint covers all the nodes. So, we 
> > will need to rewrite new checkpoint even for this file when its nodes are 
> > garbage collected... 
> 
> Yeah. In particular we'd nee to rewrite a new checkpoint when the block
> containing the old checkpoint was garbage-collected anyway.
> 
Hmm, do not get it why. Why we need this? We may just copu old checkpoint 
inact I believe. What happen If we do this? 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from miranda.se.axis.com ([193.13.178.8])
	by pentafluge.infradead.org with esmtps (Exim 4.63 #1 (Red Hat Linux))
	id 1Iazde-0000yl-0b
	for linux-mtd@lists.infradead.org; Thu, 27 Sep 2007 21:07:12 +0100
Received: from lnxricardw.se.axis.com (lnxricardw.se.axis.com [10.13.11.219])
	by miranda.se.axis.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	l8RK6ri2032713
	for <linux-mtd@lists.infradead.org>; Thu, 27 Sep 2007 22:06:53 +0200
Date: Thu, 27 Sep 2007 22:06:46 +0200 (CEST)
From: Ricard Wanderlof <ricard.wanderlof@axis.com>
To: Linux mtd <linux-mtd@lists.infradead.org>
Subject: Re: your mail
In-Reply-To: <VSNLCHNFE002syCCr8H0000c0ce@VSNLCHNFE002.VSNLXCHANGE.COM>
Message-ID: <Pine.LNX.4.64.0709272205450.28670@lnxricardw.se.axis.com>
References: <VSNLCHNFE002syCCr8H0000c0ce@VSNLCHNFE002.VSNLXCHANGE.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>


On Thu, 27 Sep 2007, Gangadhar Kodishala wrote:

> I created another partition on NAND to use specifically for the data. I
> would like to create a JFFS2 file system on this data partition, mount it
> and use it to store my application code and data files,

If you just want to create an empty JFFS2 file system, then just erase the=
=20
partition, and mount it.

/Ricard
--
Ricard Wolf Wanderl=F6f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-nfs-owner@vger.kernel.org>
Received: from fieldses.org ([173.255.197.46]:47928 "EHLO fieldses.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2388022AbeGWVgA (ORCPT <rfc822;linux-nfs@vger.kernel.org>);
        Mon, 23 Jul 2018 17:36:00 -0400
Date: Mon, 23 Jul 2018 16:33:06 -0400
From: Bruce Fields <bfields@fieldses.org>
To: Marc Eshel <eshel@us.ibm.com>
Cc: Libtirpc-devel Mailing List
        <libtirpc-devel@lists.sourceforge.net>,
        Linux NFS Mailing list <linux-nfs@vger.kernel.org>,
        linux-nfs-owner@vger.kernel.org
Subject: Re: your mail
Message-ID: <20180723203306.GA27515@fieldses.org>
References: <20180711152521.8238-1-steved@redhat.com>
 <OFA232E502.EADD3A82-ON882582D3.00667F9D-882582D3.0066E0F8@notes.na.collabserv.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <OFA232E502.EADD3A82-ON882582D3.00667F9D-882582D3.0066E0F8@notes.na.collabserv.com>
Sender: linux-nfs-owner@vger.kernel.org
List-ID: <linux-nfs.vger.kernel.org>

On Mon, Jul 23, 2018 at 11:43:55AM -0700, Marc Eshel wrote:
> Do you know of any plans to add  IETF RFC 8276 - File System Extended 
> Attributes in NFSv4 to the Linux NFS Client or Server?

I don't understand why you proposed new protocol without having anyone
in mind to implement it on the platforms where you need it.

Matt Benjamin's expressed interest in the past, but he's got a lot on
his plate so I don't know that we can count on that.

--b.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mlevitsk@redhat.com (Maxim Levitsky)
Date: Mon, 08 Apr 2019 13:04:03 +0300
Subject: your mail
In-Reply-To: <20190319152212.GC24176@localhost.localdomain>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
Message-ID: <4a3d473c8f671d59c57ec26ff5ec0879ad38bf9a.camel@redhat.com>

On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> >   -> Share the NVMe device between host and guest. 
> >      Even in fully virtualized configurations,
> >      some partitions of nvme device could be used by guests as block
> > devices 
> >      while others passed through with nvme-mdev to achieve balance between
> >      all features of full IO stack emulation and performance.
> >   
> >   -> NVME-MDEV is a bit faster due to the fact that in-kernel driver 
> >      can send interrupts to the guest directly without a context 
> >      switch that can be expensive due to meltdown mitigation.
> > 
> >   -> Is able to utilize interrupts to get reasonable performance. 
> >      This is only implemented
> >      as a proof of concept and not included in the patches, 
> >      but interrupt driven mode shows reasonable performance
> >      
> >   -> This is a framework that later can be used to support NVMe devices 
> >      with more of the IO virtualization built-in 
> >      (IOMMU with PASID support coupled with device that supports it)
> 
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
> 
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
> 
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).


Hi!

Sorry to bother you, but any update?

I was somewhat sick for the last week, now finally back in shape to continue
working on this and other tasks I have.

I am studing now the nvme target code and the io_uring to evaluate the
difficultiy of using something similiar to talk to the block device instead of /
in addtion to the  direct connection I implemented.

I would be glad to hear more feedback on this project.

I will also soon post the few fixes separately as you suggested.

Best regards,
    Maxim Levitskky

From mboxrd@z Thu Jan  1 00:00:00 1970
From: kbusch@kernel.org (Keith Busch)
Date: Tue, 19 Mar 2019 09:22:13 -0600
Subject: your mail
In-Reply-To: <20190319144116.400-1-mlevitsk@redhat.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
Message-ID: <20190319152212.GC24176@localhost.localdomain>

On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
>   -> Share the NVMe device between host and guest. 
>      Even in fully virtualized configurations,
>      some partitions of nvme device could be used by guests as block devices 
>      while others passed through with nvme-mdev to achieve balance between
>      all features of full IO stack emulation and performance.
>   
>   -> NVME-MDEV is a bit faster due to the fact that in-kernel driver 
>      can send interrupts to the guest directly without a context 
>      switch that can be expensive due to meltdown mitigation.
> 
>   -> Is able to utilize interrupts to get reasonable performance. 
>      This is only implemented
>      as a proof of concept and not included in the patches, 
>      but interrupt driven mode shows reasonable performance
>      
>   -> This is a framework that later can be used to support NVMe devices 
>      with more of the IO virtualization built-in 
>      (IOMMU with PASID support coupled with device that supports it)

Would be very interested to see the PASID support. You wouldn't even
need to mediate the IO doorbells or translations if assigning entire
namespaces, and should be much faster than the shadow doorbells.

I think you should send 6/9 "nvme/pci: init shadow doorbell after each
reset" separately for immediate inclusion.

I like the idea in principle, but it will take me a little time to get
through reviewing your implementation. I would have guessed we could
have leveraged something from the existing nvme/target for the mediating
controller register access and admin commands. Maybe even start with
implementing an nvme passthrough namespace target type (we currently
have block and file).

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chaitanya.Kulkarni@wdc.com (Chaitanya Kulkarni)
Date: Tue, 19 Mar 2019 23:49:16 +0000
Subject: your mail
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
Message-ID: <SN6PR04MB4527810F605C8ADE388E958286400@SN6PR04MB4527.namprd04.prod.outlook.com>

Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
>>    -> Share the NVMe device between host and guest.
>>       Even in fully virtualized configurations,
>>       some partitions of nvme device could be used by guests as block devices
>>       while others passed through with nvme-mdev to achieve balance between
>>       all features of full IO stack emulation and performance.
>>
>>    -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
>>       can send interrupts to the guest directly without a context
>>       switch that can be expensive due to meltdown mitigation.
>>
>>    -> Is able to utilize interrupts to get reasonable performance.
>>       This is only implemented
>>       as a proof of concept and not included in the patches,
>>       but interrupt driven mode shows reasonable performance
>>
>>    -> This is a framework that later can be used to support NVMe devices
>>       with more of the IO virtualization built-in
>>       (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).

I have the code for the NVMeOf target passthru-ctrl, I think we can use 
that as it is if you are looking for the passthru for NVMeOF.

I'll post patch-series based on the latest code base soon.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mlevitsk@redhat.com (Maxim Levitsky)
Date: Wed, 20 Mar 2019 18:30:29 +0200
Subject: your mail
In-Reply-To: <20190319152212.GC24176@localhost.localdomain>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
Message-ID: <5a56e110b062de9d448c51cf0774c5e614133873.camel@redhat.com>

On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> >   -> Share the NVMe device between host and guest. 
> >      Even in fully virtualized configurations,
> >      some partitions of nvme device could be used by guests as block
> > devices 
> >      while others passed through with nvme-mdev to achieve balance between
> >      all features of full IO stack emulation and performance.
> >   
> >   -> NVME-MDEV is a bit faster due to the fact that in-kernel driver 
> >      can send interrupts to the guest directly without a context 
> >      switch that can be expensive due to meltdown mitigation.
> > 
> >   -> Is able to utilize interrupts to get reasonable performance. 
> >      This is only implemented
> >      as a proof of concept and not included in the patches, 
> >      but interrupt driven mode shows reasonable performance
> >      
> >   -> This is a framework that later can be used to support NVMe devices 
> >      with more of the IO virtualization built-in 
> >      (IOMMU with PASID support coupled with device that supports it)
> 

> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.

I fully agree with that.
Note that to enable PASID support two things have to happen in this vendor.

1. Mature support for IOMMU with PASID support. On Intel side I know that they
only have a spec released and currently the kernel bits to support it are
placed.
I still don't know when a product actually supporting this spec is going to be
released. For other vendors (ARM/AMD/) I haven't done yet a research on state of
PASID based IOMMU support on their platforms.

2. NVMe spec has to be extended to support PASID. At minimum, we need an ability
to assign an PASID to a sq/cq queue pair and ability to relocate the doorbells,
such as each guest would get its own (hardware backed) MMIO page with its own
doorbells. Plus of course the hardware vendors have to embrace the spec. I guess
these two things will happen in collaborative manner.


> 
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
I'll do this soon. 

Also '5/9 nvme/pci: add known admin effects to augment admin effects log page'
can be considered for immediate inclusion as well, as it works around a flaw
in the NVMe controller badly done admin side effects page with no side effects
(pun intended) for spec compliant controllers (I think so). 

This can be fixed with a quirk if you prefer though.

> 
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).

I fully agree with you on that I could have used some of the nvme/target code,
and I am planning to do so eventually.

For that I would need to make my driver, to be one of the target drivers, and I
would need to add another target back end, like you said to allow my target
driver to talk directly to the nvme hardware bypassing the block layer.

Or instead I can use the block backend, 
(but note that currently the block back-end doesn't support polling which is
critical for the performance).

Switch to the target code might though have some (probably minor) performance
impact, as it would probably lengthen the critical code path a bit (I might need
for instance to translate the PRP lists I am getting from the virtual controller
to a scattergather list and back).

This is why I did this the way I did, but now knowing that probably I can afford
to loose a bit of performance, I can look at doing that.

Best regards,
Thanks in advance for the review,
	Maxim Levitsky

PS:

For reference currently the IO path looks more or less like that:

My IO thread notices a doorbell write, reads a command from a submission queue,
translates it (without even looking at the data pointer) and sends it to the
nvme pci driver together with pointer to data iterator'.

The nvme pci driver calls the data iterator N times, which makes the iterator
translate and fetch the DMA addresses where the data is already mapped on the
its pci nvme device (the mdev driver maps all the guest memory to the nvme pci
device).
The nvme pci driver uses these addresses it receives, to create a prp list,
which it puts into the data pointer.

The nvme pci driver also allocates an free command id, from a list, puts it into
the command ID and sends the command to the real hardware.

Later the IO thread calls to the nvme pci driver to poll the queue. When
completions arrive, the nvme pci driver returns them back to the IO thread.

> 
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mlevitsk@redhat.com (Maxim Levitsky)
Date: Wed, 20 Mar 2019 18:44:59 +0200
Subject: your mail
In-Reply-To: <SN6PR04MB4527810F605C8ADE388E958286400@SN6PR04MB4527.namprd04.prod.outlook.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
 <SN6PR04MB4527810F605C8ADE388E958286400@SN6PR04MB4527.namprd04.prod.outlook.com>
Message-ID: <964d501e1141b2e58665b89dd82a8b65d8db2b53.camel@redhat.com>

On Tue, 2019-03-19@23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > >    -> Share the NVMe device between host and guest.
> > >       Even in fully virtualized configurations,
> > >       some partitions of nvme device could be used by guests as block
> > > devices
> > >       while others passed through with nvme-mdev to achieve balance
> > > between
> > >       all features of full IO stack emulation and performance.
> > > 
> > >    -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > >       can send interrupts to the guest directly without a context
> > >       switch that can be expensive due to meltdown mitigation.
> > > 
> > >    -> Is able to utilize interrupts to get reasonable performance.
> > >       This is only implemented
> > >       as a proof of concept and not included in the patches,
> > >       but interrupt driven mode shows reasonable performance
> > > 
> > >    -> This is a framework that later can be used to support NVMe devices
> > >       with more of the IO virtualization built-in
> > >       (IOMMU with PASID support coupled with device that supports it)
> > 
> > Would be very interested to see the PASID support. You wouldn't even
> > need to mediate the IO doorbells or translations if assigning entire
> > namespaces, and should be much faster than the shadow doorbells.
> > 
> > I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> > reset" separately for immediate inclusion.
> > 
> > I like the idea in principle, but it will take me a little time to get
> > through reviewing your implementation. I would have guessed we could
> > have leveraged something from the existing nvme/target for the mediating
> > controller register access and admin commands. Maybe even start with
> > implementing an nvme passthrough namespace target type (we currently
> > have block and file).
> 
> I have the code for the NVMeOf target passthru-ctrl, I think we can use 
> that as it is if you are looking for the passthru for NVMeOF.
> 
> I'll post patch-series based on the latest code base soon.

I am very intersing in this code. 
Could you explain how your NVMeOF target passthrough works? 
Which components of the NVME stack does it involve?

Best regards,
	Maxim Levitsky

> > 
> > _______________________________________________
> > Linux-nvme mailing list
> > Linux-nvme at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> > 
> 
> 
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme

From mboxrd@z Thu Jan  1 00:00:00 1970
From: kbusch@kernel.org (Keith Busch)
Date: Wed, 20 Mar 2019 11:03:22 -0600
Subject: your mail
In-Reply-To: <5a56e110b062de9d448c51cf0774c5e614133873.camel@redhat.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
 <5a56e110b062de9d448c51cf0774c5e614133873.camel@redhat.com>
Message-ID: <20190320170321.GA27462@localhost.localdomain>

On Wed, Mar 20, 2019@06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend, 
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).

Oh, I think you can do polling through there. For reference, fs/io_uring.c
has a pretty good implementation that aligns with how you could use it.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mlevitsk@redhat.com (Maxim Levitsky)
Date: Wed, 20 Mar 2019 19:33:05 +0200
Subject: your mail
In-Reply-To: <20190320170321.GA27462@localhost.localdomain>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190319152212.GC24176@localhost.localdomain>
 <5a56e110b062de9d448c51cf0774c5e614133873.camel@redhat.com>
 <20190320170321.GA27462@localhost.localdomain>
Message-ID: <80d6ac26870b52d4df95dacb067a9c6f181b1581.camel@redhat.com>

On Wed, 2019-03-20@11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019@06:30:29PM +0200, Maxim Levitsky wrote:
> > Or instead I can use the block backend, 
> > (but note that currently the block back-end doesn't support polling which is
> > critical for the performance).
> 
> Oh, I think you can do polling through there. For reference, fs/io_uring.c
> has a pretty good implementation that aligns with how you could use it.


That is exactly my thought. The polling recently got lot of improvements in the
block layer, which migh make this feasable.

I will give it a try.

Best regards,
	Maxim Levitsky

From mboxrd@z Thu Jan  1 00:00:00 1970
From: stefanha@gmail.com (Stefan Hajnoczi)
Date: Thu, 21 Mar 2019 16:13:52 +0000
Subject: your mail
In-Reply-To: <20190319144116.400-1-mlevitsk@redhat.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
Message-ID: <20190321161352.GA21682@stefanha-x1.localdomain>

On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> 
> Hi everyone!
> 
> In this patch series, I would like to introduce my take on the problem of doing 
> as fast as possible virtualization of storage with emphasis on low latency.
> 
> In this patch series I implemented a kernel vfio based, mediated device that 
> allows the user to pass through a partition and/or whole namespace to a guest.
> 
> The idea behind this driver is based on paper you can find at
> https://www.usenix.org/conference/atc18/presentation/peng,
> 
> Although note that I stared the development prior to reading this paper, 
> independently.
> 
> In addition to that implementation is not based on code used in the paper as 
> I wasn't being able at that time to make the source available to me.
> 
> ***Key points about the implementation:***
> 
> * Polling kernel thread is used. The polling is stopped after a 
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising results.
> 
> * Guest sees a standard NVME device - this allows to run guest with 
> unmodified drivers, for example windows guests.
> 
> * The NVMe device is shared between host and guest.
> That means that even a single namespace can be split between host 
> and guest based on different partitions.
> 
> * Simple configuration
> 
> *** Performance ***
> 
> Performance was tested on Intel DC P3700, With Xeon E5-2620 v2 
> and both latency and throughput is very similar to SPDK.
> 
> Soon I will test this on a better server and nvme device and provide
> more formal performance numbers.
> 
> Latency numbers:
> ~80ms - spdk with fio plugin on the host.
> ~84ms - nvme driver on the host
> ~87ms - mdev-nvme + nvme driver in the guest

You mentioned the spdk numbers are with vhost-user-nvme.  Have you
measured SPDK's vhost-user-blk?

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190321/43a43762/attachment.sig>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mlevitsk@redhat.com (Maxim Levitsky)
Date: Thu, 21 Mar 2019 19:07:38 +0200
Subject: your mail
In-Reply-To: <20190321161352.GA21682@stefanha-x1.localdomain>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190321161352.GA21682@stefanha-x1.localdomain>
Message-ID: <a4dc67e66cd126892468011311ff516853754cdb.camel@redhat.com>

On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > 
> > Hi everyone!
> > 
> > In this patch series, I would like to introduce my take on the problem of
> > doing 
> > as fast as possible virtualization of storage with emphasis on low latency.
> > 
> > In this patch series I implemented a kernel vfio based, mediated device
> > that 
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
> > 
> > The idea behind this driver is based on paper you can find at
> > https://www.usenix.org/conference/atc18/presentation/peng,
> > 
> > Although note that I stared the development prior to reading this paper, 
> > independently.
> > 
> > In addition to that implementation is not based on code used in the paper
> > as 
> > I wasn't being able at that time to make the source available to me.
> > 
> > ***Key points about the implementation:***
> > 
> > * Polling kernel thread is used. The polling is stopped after a 
> > predefined timeout (1/2 sec by default).
> > Support for all interrupt driven mode is planned, and it shows promising
> > results.
> > 
> > * Guest sees a standard NVME device - this allows to run guest with 
> > unmodified drivers, for example windows guests.
> > 
> > * The NVMe device is shared between host and guest.
> > That means that even a single namespace can be split between host 
> > and guest based on different partitions.
> > 
> > * Simple configuration
> > 
> > *** Performance ***
> > 
> > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2 
> > and both latency and throughput is very similar to SPDK.
> > 
> > Soon I will test this on a better server and nvme device and provide
> > more formal performance numbers.
> > 
> > Latency numbers:
> > ~80ms - spdk with fio plugin on the host.
> > ~84ms - nvme driver on the host
> > ~87ms - mdev-nvme + nvme driver in the guest
> 
> You mentioned the spdk numbers are with vhost-user-nvme.  Have you
> measured SPDK's vhost-user-blk?

I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
vhost-user-nvme was always a bit faster but only a bit.
Thus I don't think it makes sense to benchamrk against vhost-user-blk.

Best regards,
	Maxim Levitsky

From mboxrd@z Thu Jan  1 00:00:00 1970
From: stefanha@gmail.com (Stefan Hajnoczi)
Date: Mon, 25 Mar 2019 16:46:03 +0000
Subject: your mail
In-Reply-To: <a4dc67e66cd126892468011311ff516853754cdb.camel@redhat.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
 <20190321161352.GA21682@stefanha-x1.localdomain>
 <a4dc67e66cd126892468011311ff516853754cdb.camel@redhat.com>
Message-ID: <20190325164603.GB10732@stefanha-x1.localdomain>

On Thu, Mar 21, 2019@07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > > 
> > > Hi everyone!
> > > 
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing 
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > > 
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that 
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> > > 
> > > The idea behind this driver is based on paper you can find at
> > > https://www.usenix.org/conference/atc18/presentation/peng,
> > > 
> > > Although note that I stared the development prior to reading this paper, 
> > > independently.
> > > 
> > > In addition to that implementation is not based on code used in the paper
> > > as 
> > > I wasn't being able at that time to make the source available to me.
> > > 
> > > ***Key points about the implementation:***
> > > 
> > > * Polling kernel thread is used. The polling is stopped after a 
> > > predefined timeout (1/2 sec by default).
> > > Support for all interrupt driven mode is planned, and it shows promising
> > > results.
> > > 
> > > * Guest sees a standard NVME device - this allows to run guest with 
> > > unmodified drivers, for example windows guests.
> > > 
> > > * The NVMe device is shared between host and guest.
> > > That means that even a single namespace can be split between host 
> > > and guest based on different partitions.
> > > 
> > > * Simple configuration
> > > 
> > > *** Performance ***
> > > 
> > > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2 
> > > and both latency and throughput is very similar to SPDK.
> > > 
> > > Soon I will test this on a better server and nvme device and provide
> > > more formal performance numbers.
> > > 
> > > Latency numbers:
> > > ~80ms - spdk with fio plugin on the host.
> > > ~84ms - nvme driver on the host
> > > ~87ms - mdev-nvme + nvme driver in the guest
> > 
> > You mentioned the spdk numbers are with vhost-user-nvme.  Have you
> > measured SPDK's vhost-user-blk?
> 
> I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
> vhost-user-nvme was always a bit faster but only a bit.
> Thus I don't think it makes sense to benchamrk against vhost-user-blk.

It's interesting because mdev-nvme is closest to the hardware while
vhost-user-blk is closest to software.  Doing things at the NVMe level
isn't buying much performance because it's still going through a
software path comparable to vhost-user-blk.


>From what you say it sounds like there isn't much to optimize away :(.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190325/f46e8674/attachment.sig>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Subject: Re: your mail
Date: Wed, 16 Feb 2011 13:55:42 +0200
Message-ID: <20110216115542.GE2497@legolas.emea.dhcp.ti.com>
References: <1297857190-27449-1-git-send-email-hemahk@ti.com>
Reply-To: balbi-l0cyMroinI0@public.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Hema HK <hemahk-l0cyMroinI0@public.gmane.org>
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
List-Id: linux-omap@vger.kernel.org

no subject ??

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Felipe Balbi <balbi@ti.com>
Subject: Re: your mail
Date: Wed, 16 Feb 2011 13:55:52 +0200
Message-ID: <20110216115552.GF2497@legolas.emea.dhcp.ti.com>
References: <1297857292-27494-1-git-send-email-hemahk@ti.com>
Reply-To: balbi@ti.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-omap-owner@vger.kernel.org>
Received: from na3sys009aog102.obsmtp.com ([74.125.149.69]:44060 "EHLO
	na3sys009aog102.obsmtp.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751067Ab1BPLz4 (ORCPT
	<rfc822;linux-omap@vger.kernel.org>);
	Wed, 16 Feb 2011 06:55:56 -0500
Content-Disposition: inline
In-Reply-To: <1297857292-27494-1-git-send-email-hemahk@ti.com>
Sender: linux-omap-owner@vger.kernel.org
List-Id: linux-omap@vger.kernel.org
To: Hema HK <hemahk@ti.com>
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, Felipe Balbi <balbi@ti.com>

no subject ??

-- 
balbi

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hema Kalliguddi <hemahk@ti.com>
Subject: RE: your mail
Date: Wed, 16 Feb 2011 17:37:20 +0530
Message-ID: <75570acabae28fe7c7d4ddbabc524f4e@mail.gmail.com>
References: <1297857292-27494-1-git-send-email-hemahk@ti.com> <20110216115552.GF2497@legolas.emea.dhcp.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Return-path: <linux-omap-owner@vger.kernel.org>
Received: from na3sys009aog107.obsmtp.com ([74.125.149.197]:55068 "EHLO
	na3sys009aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1758964Ab1BPMIq (ORCPT
	<rfc822;linux-omap@vger.kernel.org>);
	Wed, 16 Feb 2011 07:08:46 -0500
In-Reply-To: <20110216115552.GF2497@legolas.emea.dhcp.ti.com>
Sender: linux-omap-owner@vger.kernel.org
List-Id: linux-omap@vger.kernel.org
To: balbi@ti.com
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org

Hi,

Yes. This was broken patch. My bad... I resent the patch.

Regards,
Hema

>-----Original Message-----
>From: Felipe Balbi [mailto:balbi@ti.com]
>Sent: Wednesday, February 16, 2011 5:26 PM
>To: Hema HK
>Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi
>Subject: Re: your mail
>
>no subject ??
>
>--
>balbi
>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Felipe Balbi <balbi@ti.com>
Subject: Re: your mail
Date: Mon, 16 May 2011 12:44:43 +0300
Message-ID: <20110516094440.GQ11339@legolas.emea.dhcp.ti.com>
References: <1305538460-20980-1-git-send-email-keshava_mgowda@ti.com>
Reply-To: balbi@ti.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="f4HxWLVbzokH9yio"
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <1305538460-20980-1-git-send-email-keshava_mgowda@ti.com>
Sender: linux-kernel-owner@vger.kernel.org
To: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, balbi@ti.com, gadiyar@ti.com, sameo@linux.intel.com, parthab@india.ti.com
List-Id: linux-omap@vger.kernel.org


--f4HxWLVbzokH9yio
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
> Following 2 hwmod strcuture are added:
> UHH hwmod of usbhs with uhh base address and
> EHCI , OHCI irq and base addresses.
> TLL hwmod of usbhs with the TLL base address and irq.
>=20
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>

missing subject line.

--=20
balbi

--f4HxWLVbzokH9yio
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJN0PIIAAoJEAv8Txj19kN14ncIAIqNrkBw2eTEpLCnWPfGg/nI
ggzit3BXecgH8YaGz7/r4biI17Qqds7M4LPw0kifNd4EmxUGyxM8z6MYQTZKGmBC
z5ELV+fvYIE21IO2giVAZNefJt3KxjHzkY0H7KD5tAn3Bgw67b3AD9i4cu12H0nr
OtcyiZIbC4RQAFjD9Bp9KeGBEYQ/8wwvbylbGZFTtlwCQXFbDSSP6A2n28k0nJcR
4UDjkbHeGKJAHi8Tc8PQPB2Vg6B0/EZrzHcMR8BK7twXy1+DS0i9g3Buqx63coy2
7Xkv0ItSEccjf3oYyjbT4cmoxN0BJhwJRtJWF10TmXMvcRNSBFpNsjqtLihG0UU=
=WCrh
-----END PGP SIGNATURE-----

--f4HxWLVbzokH9yio--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Munegowda, Keshava" <keshava_mgowda@ti.com>
Subject: Re: your mail
Date: Mon, 16 May 2011 15:37:11 +0530
Message-ID: <BANLkTimp4NgmZ7Y9PmccztGyAGPNu0vC8A@mail.gmail.com>
References: <1305538460-20980-1-git-send-email-keshava_mgowda@ti.com>
	<20110516094440.GQ11339@legolas.emea.dhcp.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Return-path: <linux-omap-owner@vger.kernel.org>
Received: from na3sys009aog114.obsmtp.com ([74.125.149.211]:34336 "EHLO
	na3sys009aog114.obsmtp.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1754232Ab1EPKHO (ORCPT
	<rfc822;linux-omap@vger.kernel.org>);
	Mon, 16 May 2011 06:07:14 -0400
In-Reply-To: <20110516094440.GQ11339@legolas.emea.dhcp.ti.com>
Sender: linux-omap-owner@vger.kernel.org
List-Id: linux-omap@vger.kernel.org
To: balbi@ti.com
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, gadiyar@ti.com, sameo@linux.intel.com, parthab@india.ti.com

On Mon, May 16, 2011 at 3:14 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
>> Following 2 hwmod strcuture are added:
>> UHH hwmod of usbhs with uhh base address and
>> EHCI , OHCI irq and base addresses.
>> TLL hwmod of usbhs with the TLL base address and irq.
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
>
> missing subject line.

Ya, I have already correct it and resend this patch [RESEND] [PATCH 1/5]...

Regards
keshava

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tony Lindgren <tony@atomide.com>
Subject: Re: your mail
Date: Fri, 22 Jun 2012 01:56:06 -0700
Message-ID: <20120622085605.GB12766@atomide.com>
References: <alpine.DEB.2.00.1206211225360.10198@utopia.booyaka.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-omap-owner@vger.kernel.org>
Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:17854 "EHLO
	mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1761731Ab2FVI4J (ORCPT
	<rfc822;linux-omap@vger.kernel.org>); Fri, 22 Jun 2012 04:56:09 -0400
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1206211225360.10198@utopia.booyaka.com>
Sender: linux-omap-owner@vger.kernel.org
List-Id: linux-omap@vger.kernel.org
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, khilman@ti.com, Omar Ramirez Luna <omar.luna@linaro.org>, peter.ujfalusi@ti.com

* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
> 
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
> 
>   Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
> 
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
> 
>   Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
> 
> ----------------------------------------------------------------
> 
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
> 
> ----------------------------------------------------------------

Merging into cleanup-hwmod and merging into l-o master for testing.

Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailserv2.iuinc.com (IDENT:qmailr@mailserv2.iuinc.com [206.245.164.55])
	by puffin.external.hp.com (8.9.3/8.9.3) with SMTP id HAA29867
	for <parisc-linux@puffin.external.hp.com>; Sat, 22 Jul 2000 07:00:31 -0600
Received: from ottawa.linuxcare.com (HELO vodka.thepuffingroup.com) (216.208.98.2)
  by mailserv2.iuinc.com with SMTP; 22 Jul 2000 13:02:19 -0000
Date: Sat, 22 Jul 2000 07:56:53 -0400
From: Matthew Wilcox <matthew@wil.cx>
To: borislav dzodzo <dzodzo@students.uiuc.edu>
Cc: willy@thepuffingroup.com, parisc-linux@thepuffingroup.com
Subject: Re: your mail
Message-ID: <20000722075653.C22210@vodka.thepuffingroup.com>
References: <Pine.GSO.4.10.10007211305380.4421-100000@ux5.cso.uiuc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.GSO.4.10.10007211305380.4421-100000@ux5.cso.uiuc.edu>; from borislav dzodzo on Fri, Jul 21, 2000 at 01:06:33PM -0500
List-ID: <linux-parisc.vger.kernel.org>

On Fri, Jul 21, 2000 at 01:06:33PM -0500, borislav dzodzo wrote:
> hi i found some of your posts on 
> http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/
> and i thought you might know if 
> there already exists a linux version of fsck for 
> under pa-risc for HFS (not apple but HewlettPackard).

HP's HFS is a BSD Fast Filesystem (FFS) derivative.  There are a few
minor differences, but they are very closely related.  By studying the
HP-specific magic numbers added to recent 2.3/4 series kernels, you should
have no problem making a fsck.ufs or fsck.ffs work on Linux.  If anyone
can find one, let me know, and a mkfs would also be useful to have.

> if not... could you please tell me where are some good specs on
> HFS so that i could write my own.

-- 
Revolutions do not require corporate support.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Massimiliano Masserelli <negro@interim.it>
Subject: Re: your mail
Date: Wed, 30 Oct 2002 10:59:54 +0100
Sender: linux-raid-owner@vger.kernel.org
Message-ID: <20021030095954.GR1472@sgabanaz.interim.it>
References: <Pine.LNX.4.33.0210291720140.7119-100000@pandora.is.bizsystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-raid-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0210291720140.7119-100000@pandora.is.bizsystems.com>
To: linux-raid@vger.kernel.org
List-Id: linux-raid.ids

On Tue, Oct 29, 2002 at 05:26:23PM -0800, Michael Robinton wrote:

> There is no standard for the behavior of the motherboard bios when the
> first device 0x80 is not available at boot time. Some motherboards
> will automove 0x81 -> 0x80, some can do it as a bios change, some
> you're stuck.

Yes, I know. Anyway the problem doesn't seem connected with LILO, since
the kernel uncompresses smoothly, loads up the initrd image and THEN
hangs. The point is that the raidstart seems unable to initialize the
array if the /dev/hda disk is not present, and I can't understand why.
Is there some sort of priority between disks in a RAID-1 array?

Bye.
-- 
Massimiliano Masserelli
-------------------------------------------------------------------------------
He who hesitates is sometimes saved.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ross@lug.udel.edu (Ross Vandegrift)
Subject: Re: your mail
Date: Wed, 11 Jan 2006 12:44:33 -0500
Message-ID: <20060111174433.GA9970@lug.udel.edu>
References: <20060111144943.93BAA396A20@mxo3.broadbandsupport.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-raid-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20060111144943.93BAA396A20@mxo3.broadbandsupport.net>
Sender: linux-raid-owner@vger.kernel.org
To: bhess@patmedia.net
Cc: linux-raid@vger.kernel.org
List-Id: linux-raid.ids

On Wed, Jan 11, 2006 at 09:47:03AM -0500, bhess@patmedia.net wrote:
> Has anyone put an effort into building a raid 1 based on USB connected
> drives under Redhat 3/4 not as the root/boot
> drive.

No, I haven't actually tried this, but I do know that it'll work
without any problem.

The main issue that you'll confront - USB devices do not have fixed
device numbers.  They can change every time they are plugged/unplugged.
As a result, you may not be able to depend on your disks to always be
(for example) /dev/sde and /dev/sdf.

There's a user-space daemon called hotplug that manages this stuff.
It load appropriate drivers for the devices it sees plugged into the
USB bus.  I don't know enough about to tell you specifically how it
will handle your setup.

My initial suggestion:
	1) Start with no driver plugged
	2) cat /proc/partitions > ~/nousb
	3) Plug one drive in
	4) cat /proc/partitions > ~/oneusb
	5) Plug second drive in
	6) cat /proc/parititons > ~/twousb
	7) diff -u ~/nousb ~/oneusb
	8) diff -u ~/oneusb ~/twousb

This should give you a good idea of how the kernel treats the
situation from the device perspective.

As far as the RAID part - that's easy.  Once you know what the block
devices look like, make your RAID.  I promise the md driver will work.
I've run md across all sorts of weird device setups and so long as
it's a working block device, md is happy!

Finally, if you use mdadm's --uuid option to assemble your array after
creating it, it should just find the USB disks, regardless of where
they came up.  That way, you only need to worry about what device node
they are using when you first create the array.

Good luck! 


-- 
Ross Vandegrift
ross@lug.udel.edu

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
	--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Justin Piszcz <jpiszcz@lucidpixels.com>
Subject: Re: your mail
Date: Tue, 9 Oct 2007 06:46:41 -0400 (EDT)
Message-ID: <Pine.LNX.4.64.0710090646340.13915@p34.internal.lan>
References: <200710091156.24534.mantegazza@ill.fr>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1770962544-1191926801=:13915"
Return-path: <linux-raid-owner@vger.kernel.org>
In-Reply-To: <200710091156.24534.mantegazza@ill.fr>
Sender: linux-raid-owner@vger.kernel.org
To: =?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?= <mantegazza@ill.fr>
Cc: linux-raid@vger.kernel.org
List-Id: linux-raid.ids

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1463747160-1770962544-1191926801=:13915
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

You need to e-mail majordomo@vger.kernel.org.

On Tue, 9 Oct 2007, Fr=E9d=E9ric Mantegazza wrote:

> subscribe linux-raid
> --
>   Fr=E9d=E9ric
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
---1463747160-1770962544-1191926801=:13915--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Luca Berra <bluca@comedia.it>
Subject: Re: your mail
Date: Thu, 2 Apr 2009 08:56:49 +0200
Message-ID: <20090402065648.GA15574@maude.comedia.it>
References: <20090402041606.HVVA17102.cdptpa-omta03.mail.rr.com@Leslie>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Return-path: <linux-raid-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090402041606.HVVA17102.cdptpa-omta03.mail.rr.com@Leslie>
Sender: linux-raid-owner@vger.kernel.org
To: linux-raid@vger.kernel.org
List-Id: linux-raid.ids

On Wed, Apr 01, 2009 at 11:16:06PM -0500, Lelsie Rhorer wrote:
>8T of active space is formatted as a single Reiserfs file system.  The
....
>The issue is the entire array will occasionally pause completely for about
>40 seconds when a file is created.  This does not always happen, but the
>situation is easily reproducible.  The frequency at which the symptom
i wonder how costly b-tree operaton are for a 8Tb filesystem...

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alan Stern <stern@rowland.harvard.edu>
Subject: Re: your mail
Date: Sat, 18 Sep 2010 11:36:16 -0400 (EDT)
Message-ID: <Pine.LNX.4.44L0.1009181135000.10856-100000@netrider.rowland.org>
References: <BLU102-W16DEFB6CCB93D518FD5745EB7C0@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-pm-bounces@lists.linux-foundation.org>
In-Reply-To: <BLU102-W16DEFB6CCB93D518FD5745EB7C0@phx.gbl>
List-Unsubscribe: <https://lists.linux-foundation.org/mailman/listinfo/linux-pm>,
	<mailto:linux-pm-request@lists.linux-foundation.org?subject=unsubscribe>
List-Archive: <http://lists.linux-foundation.org/pipermail/linux-pm>
List-Post: <mailto:linux-pm@lists.linux-foundation.org>
List-Help: <mailto:linux-pm-request@lists.linux-foundation.org?subject=help>
List-Subscribe: <https://lists.linux-foundation.org/mailman/listinfo/linux-pm>,
	<mailto:linux-pm-request@lists.linux-foundation.org?subject=subscribe>
Sender: linux-pm-bounces@lists.linux-foundation.org
Errors-To: linux-pm-bounces@lists.linux-foundation.org
To: Raj Kumar <rajkumar278@hotmail.com>
Cc: linux-pm@lists.linux-foundation.org
List-Id: linux-pm@vger.kernel.org

On Sat, 18 Sep 2010, Raj Kumar wrote:

> Hi Alan,
> 
>  
> 
> I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
> 
> e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
> 
> upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
> 
> then X device driver when detects waorkload,  Can this X device driver call policy governor APIS for scaling clock or
> 
> this X device driver can directly calls DVFS driver APIs directly?

I don't know.  I have never used cpufreq and I don't know how it works.

> I just want to know from our device driver how do call DVFS driver if DVFS driver is registered with cpu frequency subsystem?

Then you should ask somebody else.

Alan Stern

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: your mail
Date: Sat, 18 Sep 2010 17:56:06 +0200
Message-ID: <20100918155606.GA16269@isilmar-3.linta.de>
References: <BLU102-W16DEFB6CCB93D518FD5745EB7C0@phx.gbl>
	<Pine.LNX.4.44L0.1009181135000.10856-100000@netrider.rowland.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-pm-bounces@lists.linux-foundation.org>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1009181135000.10856-100000@netrider.rowland.org>
List-Unsubscribe: <https://lists.linux-foundation.org/mailman/listinfo/linux-pm>,
	<mailto:linux-pm-request@lists.linux-foundation.org?subject=unsubscribe>
List-Archive: <http://lists.linux-foundation.org/pipermail/linux-pm>
List-Post: <mailto:linux-pm@lists.linux-foundation.org>
List-Help: <mailto:linux-pm-request@lists.linux-foundation.org?subject=help>
List-Subscribe: <https://lists.linux-foundation.org/mailman/listinfo/linux-pm>,
	<mailto:linux-pm-request@lists.linux-foundation.org?subject=subscribe>
Sender: linux-pm-bounces@lists.linux-foundation.org
Errors-To: linux-pm-bounces@lists.linux-foundation.org
To: Raj Kumar <rajkumar278@hotmail.com>, linux-pm@lists.linux-foundation.org
List-Id: linux-pm@vger.kernel.org

Hi Raj,

On Sat, Sep 18, 2010 at 11:36:16AM -0400, Alan Stern wrote:
> > I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
> > 
> > e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
> > 
> > upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
> > 
> > then X device driver when detects waorkload,  Can this X device driver call policy governor APIS for scaling clock or
> > 
> > this X device driver can directly calls DVFS driver APIs directly?

Best would be to register a cpufreq policy notifier,
(cpufreq_register_notifier()), and then call cpufreq_update_policy()
whenever the "X device driver" needs to modify its frequency constraints.

In addition, it would be best to discuss this on the cpufreq mailing list at

cpufreq@vger.kernel.org

Best,
	Dominik

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: your mail
Date: Mon, 26 Jun 2017 08:38:41 +0300
Message-ID: <20170626053841.GZ1248@mtr-leonro.local>
References: <20170626052117.GX1248@mtr-leonro.local>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="p+/4B2pcxE3X6xU6"
Return-path: <linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <20170626052117.GX1248-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Marcel Apfelbaum <marcel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
List-Id: linux-rdma@vger.kernel.org


--p+/4B2pcxE3X6xU6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jun 26, 2017 at 08:21:17AM +0300, Leon Romanovsky wrote:
> David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Bcc:
> Subject: Re: Proposal for the 2nd RDMA microconference (LPC 2017)
> Reply-To:
> In-Reply-To: <786f10f7-6253-c95b-49e2-a89010a43781-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> On Sun, Jun 25, 2017 at 11:43:35AM +0300, Marcel Apfelbaum wrote:
> > Hi Leon,
> >
> > Here is our proposal for the coming conference.
>
> Thanks Marcel for sending proposal, I'm looking forward to see you and
> Yuval there.
>
> In the meantime, I'm adding David who is our LPC POC and would like to
> ask some questions.
>
> >
> > Abstract
> > --------
> > QEMU's limited RDMA support leaves it behind other modern hypervisors.
> > Marcel and/or Yuval will present the implementation of an emulated RDMA
> > device, analyze its performance and usability, and finally talk about future
> > plans for a possible virtio-rdma device.
>
> How are you implementing different fabrics? Does it completely SW
> implementation and/or it requires HW beneath like prvdma? Namespaces,
> migration?
>
> What are the expectations from the community?
>
> >
> > Audience
> > --------
> > The audience is developers interested in device emulation / RDMA.
> > They can expect an interesting discussion on what are the difficulties to
> > work with RDMA in Virtual Machines and they will be welcomed to share their
> > ideas.
> >
> > Benefits to the Ecosystem
> > -------------------------
> > Knowing how to tackle RDMA on virtualization may give developers an easier
> > start on adding RDMA support to QEMU, which in turn will leverage the modern
> > RDMA cards on virtualized environments.
> >
> >
> > Thanks,
> > Marcel & Yuval



--p+/4B2pcxE3X6xU6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkhr/r4Op1/04yqaB5GN7iDZyWKcFAllQneEACgkQ5GN7iDZy
WKe3qg/9FFmwYOE7EZnJRkYJ656fs8h4gvawWWVgkwDLljwOHSaVVzCbjcCeYh+c
BrCk1B8ktLpl3sD6SEXK2NrtAT4/oMQ3jBK0nsFCDAxpsjKjr7m4Gs9i3HWo2lb3
1GdVVzSvuAz5XeqRO7OK1MAWpyYOMjhW5eL2tHKGw83ERJFvFrx7Td0fxF2hMrEx
tBJoua5k5Ond1wCcvijajrwvbXwi76uB6R855JDys6tSV+xNMxhPp2fmBOJOyKCV
e0tU37wKwX+lI4RN8sCs9ylvvOKpjEs0ygqFeqziesE2dClkIepE6e07x4ydnDdZ
EWptwcEj7yREDK4tRIB7sDBo5hygvIY5f2pz4NGbrV2lCD1xUm445PFhUlmWok9g
NGqPz88AyJ6qcK5a9jc31jN+t2y/Z6kESv+qaQo675bS//X+aA3/ZB+dOmhQ1Y8o
7GEDucW82VAyk3Ff+NOZwANpXwREsiM8oyTcw3pPP51/b6ccMWMuyGI7QiXP0hrD
8Szx/dbfxgA1uI+7FRkBrWdGbarvY5pzR4RnY06YGSBFRqNe08ZA8zZxFZQmU0U/
pyBYuUEBDV90cQ1YGT00sdL5zLgdqi5Xq2+m098B869hT7Fvnz70sZHZNd3pfY2X
cjLcrm1bF95j3oyN9OKItA9+t85bCEC8TZsXXjiO+xs5ov4z9BQ=
=f5wn
-----END PGP SIGNATURE-----

--p+/4B2pcxE3X6xU6--
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Dooks <ben-linux@fluff.org>
Subject: Re: your mail
Date: Wed, 19 May 2010 03:24:08 +0100
Message-ID: <20100519022408.GN26401@trinity.fluff.org>
References: <1274179129-14659-1-git-send-email-m.szyprowski@samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-samsung-soc-owner@vger.kernel.org>
Received: from trinity.fluff.org ([89.16.178.74]:55567 "EHLO trinity.fluff.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751880Ab0ESCYK (ORCPT
	<rfc822;linux-samsung-soc@vger.kernel.org>);
	Tue, 18 May 2010 22:24:10 -0400
Content-Disposition: inline
In-Reply-To: <1274179129-14659-1-git-send-email-m.szyprowski@samsung.com>
Sender: linux-samsung-soc-owner@vger.kernel.org
List-Id: linux-samsung-soc@vger.kernel.org
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kyungmin.park@samsung.com, ben-linux@fluff.org, kgene.kim@samsung.com

On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,

Hi, messages are supposed to have subjects... please supply one next
timne.
 
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
> 
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.

Ok, this seems to be a pretty good progression from one to the other.

I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.

Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
 
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
> 
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
>   code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
>   patches
> - some other minor cleanups (mainly c1xx to c100 renames)
> 
> This patch series includes:
> 
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: William Lee Irwin III <wli@holomorphy.com>
Subject: Re: your mail
Date: Thu, 16 Jan 2003 16:35:15 -0800
Sender: linux-scsi-owner@vger.kernel.org
Message-ID: <20030117003515.GA940@holomorphy.com>
References: <Pine.GSO.4.50.0301161854300.12779-100000@bom.adc.idt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-scsi-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.50.0301161854300.12779-100000@bom.adc.idt.com>
List-Id: linux-scsi@vger.kernel.org
To: devnull@adc.idt.com
Cc: linux-scsi@vger.kernel.org

On Thu, Jan 16, 2003 at 06:54:55PM -0500, devnull@adc.idt.com wrote:
> unsubscribe linux-scsi@vger.kernel.org

Try sending that to majordomo@vger.kernel.org instead.


Bill

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce <b3b@gmx.net>
Subject: Re: your mail
Date: Thu, 16 Jan 2003 22:08:17 -0800 (PST)
Sender: linux-scsi-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.10.10301162204550.18181-100000@gtgs.ampr.org>
References: <20030117003515.GA940@holomorphy.com>
Reply-To: Bruce <b3b@gmx.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-path: <linux-scsi-owner@vger.kernel.org>
Received: from host-66-81-119-206.rev.o1.com (bruce@host-66-81-119-206.rev.o1.com [66.81.119.206])
	by mercury.isisp.org (8.11.6/8.11.6) with ESMTP id h0H6BTM27485
	for <linux-scsi@vger.kernel.org>; Fri, 17 Jan 2003 01:11:30 -0500
In-Reply-To: <20030117003515.GA940@holomorphy.com>
List-Id: linux-scsi@vger.kernel.org
To: linux-scsi@vger.kernel.org

On Thu, 16 Jan 2003, William Lee Irwin III wrote:

> On Thu, Jan 16, 2003 at 06:54:55PM -0500, devnull@adc.idt.com wrote:
> > unsubscribe linux-scsi@vger.kernel.org
> 
> Try sending that to majordomo@vger.kernel.org instead.

     Some people just don't pay attention...
       (perhaps they can't afford it ?)


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthew Wilcox <matthew@wil.cx>
Subject: Re: your mail
Date: Wed, 17 Jun 2009 10:14:32 -0600
Message-ID: <20090617161432.GS19977@parisc-linux.org>
References: <a93061060906170908wbc8347ch366a1f30bc357672@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-scsi-owner@vger.kernel.org>
Received: from palinux.external.hp.com ([192.25.206.14]:32923 "EHLO
	mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753366AbZFQQOa (ORCPT
	<rfc822;linux-scsi@vger.kernel.org>); Wed, 17 Jun 2009 12:14:30 -0400
Content-Disposition: inline
In-Reply-To: <a93061060906170908wbc8347ch366a1f30bc357672@mail.gmail.com>
Sender: linux-scsi-owner@vger.kernel.org
List-Id: linux-scsi@vger.kernel.org
To: Koffi Nogbe <kofnews@gmail.com>
Cc: linux-scsi@vger.kernel.org

On Wed, Jun 17, 2009 at 12:08:03PM -0400, Koffi Nogbe wrote:
> How can I modify the kernel to be able to create unlimited partition
> on a single drive.

You can't in any sensible way.

> The reason for the question is I want to use one of
> my box as a storage server for fast access to the be able to create my
> RAID across all drives all the time so I want to slice the drives into
> multiple 2GB partition and used that in the RAID then use LVM to put
> it together. With SCSI drive I m stock with 15 partitions and with IDE
> 20. Any help is appreciated.

Sounds like you want to use LVM to create lots of PEs, then tie them
together into RAIDs.  http://tldp.org/HOWTO/LVM-HOWTO/tyingittogether.html
may be helpful.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

From mboxrd@z Thu Jan  1 00:00:00 1970
From: scameron@beardog.cce.hp.com
Subject: Re: your mail
Date: Wed, 13 Jan 2010 08:57:38 -0600
Message-ID: <20100113145738.GQ13413@beardog.cce.hp.com>
References: <20100113004939.289333186@suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-scsi-owner@vger.kernel.org>
Received: from g1t0027.austin.hp.com ([15.216.28.34]:17211 "EHLO
	g1t0027.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755469Ab0AMOzO (ORCPT
	<rfc822;linux-scsi@vger.kernel.org>); Wed, 13 Jan 2010 09:55:14 -0500
Content-Disposition: inline
In-Reply-To: <20100113004939.289333186@suse.com>
Sender: linux-scsi-owner@vger.kernel.org
List-Id: linux-scsi@vger.kernel.org
To: Jeff Mahoney <jeffm@suse.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Linux SCSI <linux-scsi@vger.kernel.org>

On Tue, Jan 12, 2010 at 07:49:00PM -0500, Jeff Mahoney wrote:
> Subject: [patch 5/6] hpsa: Fix section mismatch
> References: <20100113004855.550486769@suse.com>
> Content-Disposition: inline; filename=patches.rpmify/hpsa-fix-section-mismatch
> 
>  hpsa_pci_init calls hpsa_interrupt_mode which is a __devinit function.
>  hpsa_pci_init is only called by hpsa_init_one which is also __devinit, so
>  mark it __devinit as well.
> 
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> ---
>  drivers/scsi/hpsa.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -3111,7 +3111,7 @@ default_int_mode:
>  	return;
>  }
>  
> -static int hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
> +static int __devinit hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
>  {
>  	ushort subsystem_vendor_id, subsystem_device_id, command;
>  	__u32 board_id, scratchpad = 0;
> 

Thanks.

-- steve


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paul Mundt <lethal@linux-sh.org>
Date: Tue, 20 Jan 2009 03:21:44 +0000
Subject: Re: your mail
Message-Id: <20090120032144.GC12965@linux-sh.org>
List-Id: <linux-sh.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-sh@vger.kernel.org

On Tue, Jan 13, 2009 at 03:45:47PM +0000, Steve Glendinning wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Tue, 13 Jan 2009 15:22:36 +0000
> Subject: [PATCH 0/3] sh: convert platforms to use smsc911x
> 
> This patchset, intended for 2.6.30, converts all in-tree sh platforms 
> from smc911x to the actively maintained smsc911x driver.
> 
> I've rebased and fixed up the patchset against the current linus tree, 
> please let me know if I should rebase it against another instead.
> 
> Steve Glendinning (3):
>   sh: convert magicpanelr2 platform to use smsc911x
>   sh: convert ap325rxa platform to use smsc911x
>   sh: convert rsk7203 platform to use smsc911x
> 
Thanks, these are already in the queue, they will be included in the next
merge.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gerald Emig <gme@emig-software.de>
Subject: Re: your mail
Date: Tue, 27 Aug 2002 11:59:45 +0200 (CEST)
Sender: linux-serial-owner@vger.kernel.org
Message-ID: <Pine.LNX.4.33.0208271155010.5238-100000@emig4.heisch.inka.de>
References: <D3AF5F134D627243993F2F2FC32EE4D20CE1CD@mailman.eason.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-path: <linux-serial-owner@vger.kernel.org>
In-Reply-To: <D3AF5F134D627243993F2F2FC32EE4D20CE1CD@mailman.eason.com>
List-Id: linux-serial@vger.kernel.org
To: Alex Pavloff <apavloff@eason.com>
Cc: "'linux-serial@vger.kernel.org'" <linux-serial@vger.kernel.org>


To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.

On Mon, 26 Aug 2002, Alex Pavloff wrote:

>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19.  While seeminly simple to do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.  First
> used by the Modicon PLCs, it's found on a variety of devices from a variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library", and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5 character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed device.
>
> Following the last transmitted character, a similar interval of at least 3.5
> character times marks the end of the message. A new message can begin after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off with
> termios.  To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>

Gerald Emig




From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex Pavloff <apavloff@eason.com>
Subject: RE: your mail
Date: Tue, 27 Aug 2002 09:55:04 -0700
Sender: linux-serial-owner@vger.kernel.org
Message-ID: <D3AF5F134D627243993F2F2FC32EE4D20CE1CE@mailman.eason.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Return-path: <linux-serial-owner@vger.kernel.org>
List-Id: linux-serial@vger.kernel.org
To: 'Gerald Emig' <gme@emig-software.de>
Cc: "'linux-serial@vger.kernel.org'" <linux-serial@vger.kernel.org>


Hi Gerald, here's some more info:

Sending data isn't the problem.  The problem is acting as a slave and
receiving unsolicited packets from a master.   I need to determine when a
packet is complete.  If I was sending the packets (which I have done before
and am doing now), I can cheat a bit because I know the length of the packet
I'm "supposed" to be getting back.   I can't do that when acting as a slave.

This is different that the other protocol I'm familiar with.

GE's SNP uses two packets -- the first fixed size and containing the length
of the second size.
AB's DF1 has a fixed packet structure with many special characaters that
makes it easy to pull in a piece at a time

With Modbus RTU I neither know how long a packet is going to be, nor do I
have a sequence of bytes that can be used to judge the end of a packet.  I
need to be able to understand that 3.5 characters times of nothing means the
end of the packet.

Do I need a line discipline for this one portion of the driver?

Alex Pavloff
Software Engineer
Eason Technology
 


-----Original Message-----
From: Gerald Emig [mailto:gme@emig-software.de]
Sent: Tuesday, August 27, 2002 3:00 AM
To: Alex Pavloff
Cc: 'linux-serial@vger.kernel.org'
Subject: Re: your mail



To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.

On Mon, 26 Aug 2002, Alex Pavloff wrote:

>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19.  While seeminly simple to
do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.
First
> used by the Modicon PLCs, it's found on a variety of devices from a
variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library",
and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5
character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in
the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed
device.
>
> Following the last transmitted character, a similar interval of at least
3.5
> character times marks the end of the message. A new message can begin
after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion
of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off
with
> termios.  To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>

Gerald Emig



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Subject: Re: your mail
Date: Tue, 24 Aug 2004 11:39:46 +0200
Sender: linux-serial-owner@vger.kernel.org
Message-ID: <20040824093942.GO18334@lug-owl.de>
References: <200408240805.08811.fmmarzoa@softronica.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="88pBQ1/6ie/nQzMF"
Return-path: <linux-serial-owner@vger.kernel.org>
Received: from dvmwest.gt.owl.de ([62.52.24.140]:42408 "EHLO dvmwest.gt.owl.de")
	by vger.kernel.org with ESMTP id S267348AbUHXJkU (ORCPT
	<rfc822;linux-serial@vger.kernel.org>);
	Tue, 24 Aug 2004 05:40:20 -0400
Content-Disposition: inline
In-Reply-To: <200408240805.08811.fmmarzoa@softronica.org>
List-Id: linux-serial@vger.kernel.org
To: "Francisco M. Marzoa Alonso" <fmmarzoa@softronica.org>
Cc: linux-serial@vger.kernel.org


--88pBQ1/6ie/nQzMF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-08-24 08:05:08 +0200, Francisco M. Marzoa Alonso <fmmarzoa@sof=
tronica.org>
wrote in message <200408240805.08811.fmmarzoa@softronica.org>:
> >>       TOut.tv_sec =3D Wait / 1000;
> >>       TOut.tv_usec =3D Wait % 1000;
> >
> >So "Wait" is in milli-seconds? That doesn't look correct, then:)
> >
> >        TOut.tv_sec =3D Wait / 1000;
> >        TOut.tv_usec =3D (Wait % 1000) * 1000;
>=20
> Sure you're right, but this is a thing that I do not understand. I made a=
=20
> function GetTickCount to emulate Window's one based on gettimeofday and s=
ee=20
> that milliseconds on timeval structure can have values up to 999999 when =
I=20
> expect to found a maximum value of 999 as there are only 1000 millisecond=
s in=20
> a second.

Notice, it's not "tv_msec" but "tv_usec", which is micro-seconde and
not milli-seconds. A small 'u' is commonly used instead of the greek
'=B5', because '=B5' won't be properly handled by all email clients, let
alone in code to be compiled.

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 fuer einen Freien Staat voll Freier B=FCrger" | im Internet! |   im Irak! =
  O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--88pBQ1/6ie/nQzMF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBKwzbHb1edYOZ4bsRAiezAJ9cFpg8uAwZsAfyxb6wXs136hkLEQCfdweU
DPS/tkDQq6ccLx6K2vP7Ddo=
=bLQ1
-----END PGP SIGNATURE-----

--88pBQ1/6ie/nQzMF--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=cigD=YT=vger.kernel.org=linux-serial-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 58E3ACA9EB9
	for <linux-serial@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:22 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 26B5D214DA
	for <linux-serial@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=default; t=1572118222;
	bh=1vWJNlJ9nmxdq2/TYTJ8H4g9od0RudmBwjhdidF/U3A=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From;
	b=qAoG0yEl+vb0eR2YAC9g7ykvAnbNBF278ZjZNheLrl1ceQWrgYU/RNIm6uXZvEx1K
	 5WUFBknIxWxfu/FeoN2+LHVDV2erSLCsAb9MzpetDMujiBbMODo8dm+7UuM70mPdN6
	 bdjkQ12H4KN+YgQ+ZUGUYFSUkW4dMC10WD9UV3gY=
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726386AbfJZTaV (ORCPT
        <rfc822;linux-serial@archiver.kernel.org>);
        Sat, 26 Oct 2019 15:30:21 -0400
Received: from mail.kernel.org ([198.145.29.99]:57924 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726350AbfJZTaV (ORCPT <rfc822;linux-serial@vger.kernel.org>);
        Sat, 26 Oct 2019 15:30:21 -0400
Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by mail.kernel.org (Postfix) with ESMTPSA id 9081D20863;
        Sat, 26 Oct 2019 19:30:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=default; t=1572118221;
        bh=1vWJNlJ9nmxdq2/TYTJ8H4g9od0RudmBwjhdidF/U3A=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=Hi2r2tM6TywiRAJPIiqblSIrVQlGBlYTNlHn/wq31sE5yhsBzHjW7cjrmAnMCq5AX
         amDA7DsHIXtCXm0xWGwyuIDNV/ta6Tivu3T9wVbhYe7ou371SsYBOGPq0tR7qgzHM6
         paQ0mVgIjrcv6ecZPQNeoZaEYDzKQRQIoq55wABA=
Date:   Sat, 26 Oct 2019 21:30:18 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Frank Wunderlich <frank-w@public-files.de>
Cc:     linux-mediatek@lists.infradead.org,
        Matthias Brugger <matthias.bgg@gmail.com>,
        linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20191026193018.GA812200@kroah.com>
References: <20191026192359.27687-1-frank-w@public-files.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191026192359.27687-1-frank-w@public-files.de>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-serial-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-serial.vger.kernel.org>
X-Mailing-List: linux-serial@vger.kernel.org

On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one

Odd email with no subject line :(

Plaese fix up and resend.

thanks,

greg k-h-

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=liNn=C3=vger.kernel.org=linux-serial-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 6A8B7C43463
	for <linux-serial@archiver.kernel.org>; Fri, 18 Sep 2020 07:56:41 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 21D152100A
	for <linux-serial@archiver.kernel.org>; Fri, 18 Sep 2020 07:56:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=default; t=1600415801;
	bh=oO715/HpRiUMNzizx1aCANuY18d1YuqSVm+tLPjr7jw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From;
	b=EiXvBYCUz/gpZ7B1X/BalHrKOcqdCg8X21sHdlinD9AEo9qW0HHVhTvJD0m9XlewB
	 YKPj6StGGtJ7VTyDzJEpHDn9ZDNbr+Awq6Ou3DumGXq71xY2SGl0BxhKtomCoxZdY1
	 oiXlA4dlXJO//g2uDIMS7LkQiIP6Uq0x+yD/dV6A=
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726148AbgIRH4k (ORCPT
        <rfc822;linux-serial@archiver.kernel.org>);
        Fri, 18 Sep 2020 03:56:40 -0400
Received: from mail-lf1-f42.google.com ([209.85.167.42]:37519 "EHLO
        mail-lf1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726079AbgIRH4k (ORCPT
        <rfc822;linux-serial@vger.kernel.org>);
        Fri, 18 Sep 2020 03:56:40 -0400
Received: by mail-lf1-f42.google.com with SMTP id z19so5133000lfr.4
        for <linux-serial@vger.kernel.org>; Fri, 18 Sep 2020 00:56:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=oO715/HpRiUMNzizx1aCANuY18d1YuqSVm+tLPjr7jw=;
        b=gjaaoW2nBE6XR7xMd0288rUgjhN9SUV4IKao7cUjbmkPJW4yYb25SYZ1zmLfiUWk+L
         ef1Jhz1OQIm0TsviJNw2j5sESnykmoTSBEuuK88zUUsNFY4kc4DiduriOMpu+3YjNW5n
         kcY9SDriX7+ZCHiAaT3qALCpI6D+E4kRWasmTc+TLKCzlT05BPhHlEqeObU8ulJLvS/A
         o8s/r0plWsE/Cketiepapo488obACDwKcAfiKz7r3F2E/RFKHCAbhrxahdufpMI6RpPb
         QNEtPmtTeUzf4/4g6yW6c9l4cMZa2HK30mhM5Svmxpm1ev+DP+hv0CwUUTdO/8BCkP7S
         4B/A==
X-Gm-Message-State: AOAM532+qJZgqZG1sVEWPQrTp13+1UTBXo8lH8nws+zSWpFPLsCFotqM
        MHoO51XmNK6Apg+wvdoY07KivNcyGIQ=
X-Google-Smtp-Source: ABdhPJwuGVJ98OYTxXbiIcqWS91Xo4nxZSGbCf8mlfENzHKaPjhzRfewLW2hHyCbZhhP4vdMkwLHvQ==
X-Received: by 2002:ac2:5e2a:: with SMTP id o10mr10036069lfg.315.1600415798468;
        Fri, 18 Sep 2020 00:56:38 -0700 (PDT)
Received: from xi.terra (c-beaee455.07-184-6d6c6d4.bbcust.telenor.se. [85.228.174.190])
        by smtp.gmail.com with ESMTPSA id q24sm439840lfo.149.2020.09.18.00.56.37
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 18 Sep 2020 00:56:37 -0700 (PDT)
Received: from johan by xi.terra with local (Exim 4.93.0.4)
        (envelope-from <johan@kernel.org>)
        id 1kJBFx-00079O-GN; Fri, 18 Sep 2020 09:56:33 +0200
Date:   Fri, 18 Sep 2020 09:56:33 +0200
From:   Johan Hovold <johan@kernel.org>
To:     "Barnett, Andy" <Andy.Barnett@nttdata.com>
Cc:     "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20200918075633.GQ24441@localhost>
References: <CY4PR1201MB25321441CB372AD9068F8C458D2C0@CY4PR1201MB2532.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CY4PR1201MB25321441CB372AD9068F8C458D2C0@CY4PR1201MB2532.namprd12.prod.outlook.com>
Precedence: bulk
List-ID: <linux-serial.vger.kernel.org>
X-Mailing-List: linux-serial@vger.kernel.org

On Thu, Sep 03, 2020 at 05:36:34PM +0000, Barnett, Andy wrote:
> Title - Edgport/4 compatibility question

> Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

Please resend with a proper Subject line and without the above
disclaimer.

And remember to CC the USB list (linux-usb@vger.kernel.org).

Johan

From mboxrd@z Thu Jan  1 00:00:00 1970
From: <rtlynch@aracnet.com>
Date: Fri, 25 Sep 1998 17:26:40 +0000
Subject: Re: your mail
Message-Id: <marc-linux-sound-90682133207282@msgid-missing>
List-Id: <linux-sound.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-sound@vger.kernel.org

You need the isapnp package. This package has tools to inspect isa cards 
and also to activate the recomended pnp settings. I belive the home page
is at http://www.roestock.demon.co.uk/isapnptools

	-Rusty Lynch

On Thu, 24 Sep 1998, Jonathan Herringer (PHY) wrote:

> I have a PnP Sound blaster card  that can't get detected by linux.  I have
> soft booted from widows, dos and it still doesnt' get detected.
> 
> I got the latest version of the kernel (2.1.122) with plug and play
> support (but couldn't find any thing on how to configure the PnP)
> 
> Can any one suggest reading material etc...  I have read the Sound HOW-To
> 
> 
> Thanks,
> Jonathan Herringer
> 
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bill Nottingham <notting@redhat.com>
Date: Sat, 01 May 1999 02:35:09 +0000
Subject: Re: your mail
Message-Id: <marc-linux-sound-92552715502236@msgid-missing>
List-Id: <linux-sound.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-sound@vger.kernel.org

jason (rohwedde@uiuc.edu) said: 
> Does anyone know how to make a pci card with a ensoniq es1370 chipset on it
> work with linux??  It came out of a gateway.. thanks for any help

You should just be able to use the es1370 driver, either the one
in the standard 2.2 kernel or in the ALSA project.

Bill

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Brown.K <brownk30-FLCLp+oK/ug@public.gmane.org>
Subject: Your Mail
Date: 10 Aug 2009 16:47:17 -0000
Message-ID: <20090810164717.30842.qmail@2068.net>
Reply-To: brownk30-k+OT61UuxXo@public.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Return-path: <spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/spi-devel-general>,
	<mailto:spi-devel-general-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=spi-devel-general>
List-Post: <mailto:spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
List-Help: <mailto:spi-devel-general-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/spi-devel-general>,
	<mailto:spi-devel-general-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=subscribe>
Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
List-Id: linux-spi.vger.kernel.org



Its a pleasure to be in contact with you today. I wish to let you know that I have a client who wants to invest in your country. We will eventually fly into your country to visit you.

 

 

 I will give you more details and how much he wishes to invest, if you will assure us that you will be a reliable Investor, If you can handle this Investment Procurement in your country , please provide your response to discuss more and I will study your Feasibility appraisal because this is a genuine business we need to establish in your country.

 

 

You have to be diligent,honest and be focused to do business and posses managerial abilities. Note that a fully signed and stamped Memorandum of Understanding will be initiated in this business venture to aid in guiding both parties & commitments in this transaction.

Kindly send me the below information for my perusal:

 

1. Your Complete Full Names 2. Your Residential Address 3. Your age and Occupation 4. Your Phone and Fax Numbers for Easy and Faster Communication.



[For your information: FRAUDULENT OR DUBIOUS ELEMENTS ARE NOT ALLOWED!!]

 

Thanks for your anticipated cooperation. Have a nice day while i wait for your answer now.

Sir Kelly Brown

------------------------



Doing Good Business Brings Good Money: B & K Consultants.





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id A10BA273F3;
	Mon, 16 Oct 2023 12:34:57 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=inria.fr
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=inria.fr
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=inria.fr header.i=@inria.fr header.b="lEz8DQH+"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=enH1ft/wvZkvblwLLKmG5GGnmfYvvr7ku6OEydqrNdw=;
  b=lEz8DQH+SODDiRznX7ofAIvwa4C2i+SI7wIZUxIqag9IwYPJyAmhVkvh
   9PBsZuNG9TuiEYM1cOuHMevqwraxSxL5FXfMvaBsNC5BDsTuMA8yztxR5
   4zcAjNgSF9Qm+Aad9Fwq4rJyvtXo27eRl1dQt5EVL97dt1VltZZQ9kSGn
   o=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="6.03,229,1694728800"; 
   d="scan'208";a="68833400"
Received: from dhcp-138-246-3-50.dynamic.eduroam.mwn.de (HELO hadrien) ([138.246.3.50])
  by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 14:34:48 +0200
Date: Mon, 16 Oct 2023 14:34:48 +0200 (CEST)
From: Julia Lawall <julia.lawall@inria.fr>
To: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
cc: outreachy@lists.linux.dev, gregkh@linuxfoundation.org, 
    linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <ZS0tGLOJxUztxbKj@gilbert-PC>
Message-ID: <3c8e9839-78f0-bb72-a195-ee4c54b68c7f@inria.fr>
References: <ZS0tGLOJxUztxbKj@gilbert-PC>
Precedence: bulk
X-Mailing-List: linux-staging@lists.linux.dev
List-Id: <linux-staging.lists.linux.dev>
List-Subscribe: <mailto:linux-staging+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:linux-staging+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII



On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:

> linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> Bcc:
> Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
>  condition tests
> Reply-To:
> In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
>
> On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > around condition tests.
> >
> > If you need to make any changes to the patch, there is no need to give the
> > count of the changes.  It doesn't matter if it's 47, 46, 35, etc.
> >
> > julia
> >
> Hi Julia,
>
> I added the number because I saw I similar commit on the logs that did
> so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)

OK, I still think it's pointless...  The person who looks at the commit 5
years from now won't care about this information.  They care about what
you did and why.

julia


> > >
> > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > ---
> > >  drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > >  1 file changed, 36 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > index eb63daaca702..e8ddd691b788 100644
> > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > >  			/* SET_FEATURE */
> > >  			recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > >  			selector  = le16_to_cpu(p_ctrl->wValue);
> > > -			if ((recipient == USB_RECIP_DEVICE) &&
> > > -			    (selector == USB_DEVICE_TEST_MODE)) {
> > > +			if (recipient == USB_RECIP_DEVICE &&
> > > +			    selector == USB_DEVICE_TEST_MODE) {
> > >  				wIndex = le16_to_cpu(p_ctrl->wIndex);
> > >  				test_mode = (u32)(wIndex >> 8);
> > >  				_nbu2ss_set_test_mode(udc, test_mode);
> > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > >  	u32		num;
> > >  	u32		data;
> > >
> > > -	if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > +	if (ep->epnum == 0 || udc->vbus_active == 0)
> > >  		return	-EINVAL;
> > >
> > >  	num = ep->epnum - 1;
> > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > >  	u32		data;
> > >
> > >  	data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > -	if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > >  		return;		/* Not Support DMA */
> > >
> > >  	num = ep->epnum - 1;
> > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > >  		return;		/* VBUS OFF */
> > >
> > >  	data = _nbu2ss_readl(&preg->USBSSCONF);
> > > -	if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > >  		return;		/* Not Support DMA */
> > >
> > >  	num = ep->epnum - 1;
> > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > >  	union usb_reg_access  temp_32;
> > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > -	if ((length > 0) && (length < sizeof(u32))) {
> > > +	if (length > 0 && length < sizeof(u32)) {
> > >  		temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > >  		for (i = 0 ; i < length ; i++)
> > >  			p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > >  	union usb_reg_access  temp_32;
> > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > -	if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > +	if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > >  		for (i = 0 ; i < i_remain_size ; i++)
> > >  			temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > >  		_nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > >  		return result;
> > >  	}
> > >
> > > -	if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > +	if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > >  		p_buffer += result;
> > >  		result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > >  		req->div_len = result;
> > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > >  		req->req.actual += result;
> > >  		i_recv_length -= result;
> > >
> > > -		if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > +		if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > >  			p_buffer += result;
> > >  			i_remain_size -= result;
> > >
> > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > >  	req->req.actual += result;
> > >
> > > -	if ((req->req.actual == req->req.length) ||
> > > -	    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > +	if (req->req.actual == req->req.length ||
> > > +	    (req->req.actual % ep->ep.maxpacket) != 0) {
> > >  		result = 0;
> > >  	}
> > >
> > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > >  	i_buf_size = min((req->req.length - req->req.actual), data_size);
> > >
> > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > -	    (i_buf_size  >= sizeof(u32))) {
> > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > +	    i_buf_size  >= sizeof(u32)) {
> > >  		nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > >  	} else {
> > >  		i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > >  			}
> > >  		}
> > >  	} else {
> > > -		if ((req->req.actual == req->req.length) ||
> > > -		    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > +		if (req->req.actual == req->req.length ||
> > > +		    (req->req.actual % ep->ep.maxpacket) != 0) {
> > >  			result = 0;
> > >  		}
> > >  	}
> > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > >  	num = ep->epnum - 1;
> > >
> > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > -	    (data_size >= sizeof(u32))) {
> > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > +	    data_size >= sizeof(u32)) {
> > >  		nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > >  	} else {
> > >  		data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > >  	u8		num;
> > >  	u32		data;
> > >
> > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > +	if (ep_adrs == 0 || ep_adrs == 0x80)
> > >  		return;
> > >
> > >  	num = (ep_adrs & 0x7F) - 1;
> > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > >  	struct nbu2ss_ep *ep;
> > >  	struct fc_regs __iomem *preg = udc->p_regs;
> > >
> > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > +	if (ep_adrs == 0 || ep_adrs == 0x80) {
> > >  		if (bstall) {
> > >  			/* Set STALL */
> > >  			_nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > >  	u8	ep_adrs;
> > >  	int	result = -EOPNOTSUPP;
> > >
> > > -	if ((udc->ctrl.wLength != 0x0000) ||
> > > -	    (direction != USB_DIR_OUT)) {
> > > +	if (udc->ctrl.wLength != 0x0000 ||
> > > +	    direction != USB_DIR_OUT) {
> > >  		return -EINVAL;
> > >  	}
> > >
> > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > >  	u8	ep_adrs;
> > >  	int	result = -EINVAL;
> > >
> > > -	if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > +	if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > >  		return result;
> > >
> > >  	length =
> > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > >  	int		result = 0;
> > >  	u32		wValue = le16_to_cpu(udc->ctrl.wValue);
> > >
> > > -	if ((udc->ctrl.bRequestType != 0x00)	||
> > > -	    (udc->ctrl.wIndex != 0x0000)	||
> > > -		(udc->ctrl.wLength != 0x0000)) {
> > > +	if (udc->ctrl.bRequestType != 0x00	||
> > > +	    udc->ctrl.wIndex != 0x0000		||
> > > +		udc->ctrl.wLength != 0x0000) {
> > >  		return -EINVAL;
> > >  	}
> > >
> > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > >  {
> > >  	u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > >
> > > -	if ((udc->ctrl.wIndex != 0x0000)	||
> > > -	    (udc->ctrl.wLength != 0x0000)	||
> > > -		(udc->ctrl.bRequestType != 0x00)) {
> > > +	if (udc->ctrl.wIndex != 0x0000	||
> > > +	    udc->ctrl.wLength != 0x0000	||
> > > +		udc->ctrl.bRequestType != 0x00) {
> > >  		return -EINVAL;
> > >  	}
> > >
> > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > >  	}
> > >
> > >  #ifdef USE_DMA
> > > -	if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > -	    (req->req.dma != 0))
> > > +	if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > +	    req->req.dma != 0)
> > >  		_nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > >  #endif
> > >
> > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > >  		mpkt = ep->ep.maxpacket;
> > >  		size = preq->actual % mpkt;
> > >  		if (size > 0) {
> > > -			if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > +			if ((preq->actual & 0x03) == 0 && size < mpkt)
> > >  				_nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > >  		} else {
> > >  			_nbu2ss_epn_in_int(udc, ep, req);
> > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > >  	}
> > >
> > >  	ep_type = usb_endpoint_type(desc);
> > > -	if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > -	    (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > +	if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > +	    ep_type == USB_ENDPOINT_XFER_ISOC) {
> > >  		pr_err(" *** %s, bat bmAttributes\n", __func__);
> > >  		return -EINVAL;
> > >  	}
> > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > >  	if (udc->vbus_active == 0)
> > >  		return -ESHUTDOWN;
> > >
> > > -	if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > +	if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > >  		dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > >  		return -ESHUTDOWN;
> > >  	}
> > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > >  		}
> > >  	}
> > >
> > > -	if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > -	    (req->req.dma != 0))
> > > +	if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > +	    req->req.dma != 0)
> > >  		_nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > >  #endif
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > >
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA4941CF87;
	Mon, 16 Oct 2023 12:42:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WvEKempL"
Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-5a7afd45199so56476427b3.0;
        Mon, 16 Oct 2023 05:42:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1697460171; x=1698064971; darn=lists.linux.dev;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=Tb5AOkfc3GSuO5Ciat2viUgVFSJvlxY/wYiGaxPQOYo=;
        b=WvEKempLsygo0mwa3IwvDPkjc6xeeeOL4jzOphIOWRrOq1THEmpCsMRBoLcdj6IWVJ
         3G5VfYusOrGqCww+1d82s1gtHbETuSvQhYsDt0u9BvhcI+7QWUgVOj1qShEfAdHoeJss
         DvsZxvEn3WNNH8sDQvsahOmvNe0qO4EVAfTeKhRYwhoGPzC5f53ioFV1MsEGWHumXtlP
         SNaM2gNr0TG/j7mAwb5mmtT3qo+X48QkjusPKpcJugeriIN2ZOwEd2EyH6gQLMBJfhzY
         SqatBTjVNxakjmc+2tggwrU6vcuHBP32lTYEB1Bz9Ky6ArMcHReKYZF7+Bu07gMn28Pe
         tbCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1697460171; x=1698064971;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Tb5AOkfc3GSuO5Ciat2viUgVFSJvlxY/wYiGaxPQOYo=;
        b=ZsPasYYUOMSewEyN3YyYBJaI8kH8b4fWMngf4wpEVxy0Vr11T2+AhJY7kqFWGRSY62
         9xWipErCTNQDTAK2N5y6fAHslhnuzLKfSQcPmfMRR8KsUvQp+cPI8GTUszKLPEVgf3Z3
         KSBbFI+OCKvX30y3ZxAkfzYdp8WdOQ1y+kcdYwjL5C7RvyrNDjq/CYPY1m/ujKtYY0+1
         sP/n52bSrq+dvkNgvcye9+N55WNpQsYdZ7euTEVGHOOAV8PVxAEoMNDSTJh80wHY0kAb
         RtxF8K6/B3+4X3/s9kUM1YyHmlcactJElFuelbgmP0y9o1E5Xlv/jBfS0YAEZDuvUqJZ
         lehA==
X-Gm-Message-State: AOJu0YwPzUOBHyGIBLtZ2uXFQUBnf7RipJySaFaxdMkeX+Pt3/kDmAZ3
	EXfmBi3HaipwABFWsYKR39VvuvdSCeykFyd9tLA=
X-Google-Smtp-Source: AGHT+IHjeiH9CPs/QUcGJxhzaBAyZrczg6LMTKmKEMDv64boneqzJxX95fopg/vHve5mI3LibpHeyA==
X-Received: by 2002:a81:ac5b:0:b0:5a7:afc9:3579 with SMTP id z27-20020a81ac5b000000b005a7afc93579mr19492476ywj.18.1697460170675;
        Mon, 16 Oct 2023 05:42:50 -0700 (PDT)
Received: from gilbert-PC ([105.112.31.148])
        by smtp.gmail.com with ESMTPSA id i132-20020a81548a000000b005a7d9fca87dsm2148071ywb.107.2023.10.16.05.42.45
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 16 Oct 2023 05:42:48 -0700 (PDT)
Date: Mon, 16 Oct 2023 13:42:42 +0100
From: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>, outreachy@lists.linux.dev
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org
Subject: Re: your mail
Message-ID: <ZS0vwhwxUkI6n8I6@gilbert-PC>
References: <ZS0tGLOJxUztxbKj@gilbert-PC>
 <3c8e9839-78f0-bb72-a195-ee4c54b68c7f@inria.fr>
Precedence: bulk
X-Mailing-List: linux-staging@lists.linux.dev
List-Id: <linux-staging.lists.linux.dev>
List-Subscribe: <mailto:linux-staging+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:linux-staging+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3c8e9839-78f0-bb72-a195-ee4c54b68c7f@inria.fr>

On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
> 
> 
> On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> 
> > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > Bcc:
> > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> >  condition tests
> > Reply-To:
> > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> >
> > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > >
> > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > around condition tests.
> > >
> > > If you need to make any changes to the patch, there is no need to give the
> > > count of the changes.  It doesn't matter if it's 47, 46, 35, etc.
> > >
> > > julia
> > >
> > Hi Julia,
> >
> > I added the number because I saw I similar commit on the logs that did
> > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> 
> OK, I still think it's pointless...  The person who looks at the commit 5
> years from now won't care about this information.  They care about what
> you did and why.
> 
> julia
> 
Ok that make sense. I will revise it. Do I send revision patch now or
later today?
> 
> > > >
> > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > ---
> > > >  drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > >  1 file changed, 36 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > index eb63daaca702..e8ddd691b788 100644
> > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > >  			/* SET_FEATURE */
> > > >  			recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > >  			selector  = le16_to_cpu(p_ctrl->wValue);
> > > > -			if ((recipient == USB_RECIP_DEVICE) &&
> > > > -			    (selector == USB_DEVICE_TEST_MODE)) {
> > > > +			if (recipient == USB_RECIP_DEVICE &&
> > > > +			    selector == USB_DEVICE_TEST_MODE) {
> > > >  				wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > >  				test_mode = (u32)(wIndex >> 8);
> > > >  				_nbu2ss_set_test_mode(udc, test_mode);
> > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > >  	u32		num;
> > > >  	u32		data;
> > > >
> > > > -	if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > +	if (ep->epnum == 0 || udc->vbus_active == 0)
> > > >  		return	-EINVAL;
> > > >
> > > >  	num = ep->epnum - 1;
> > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > >  	u32		data;
> > > >
> > > >  	data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > -	if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > >  		return;		/* Not Support DMA */
> > > >
> > > >  	num = ep->epnum - 1;
> > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > >  		return;		/* VBUS OFF */
> > > >
> > > >  	data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > -	if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > >  		return;		/* Not Support DMA */
> > > >
> > > >  	num = ep->epnum - 1;
> > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > >  	union usb_reg_access  temp_32;
> > > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > -	if ((length > 0) && (length < sizeof(u32))) {
> > > > +	if (length > 0 && length < sizeof(u32)) {
> > > >  		temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > >  		for (i = 0 ; i < length ; i++)
> > > >  			p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > >  	union usb_reg_access  temp_32;
> > > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > -	if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > +	if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > >  		for (i = 0 ; i < i_remain_size ; i++)
> > > >  			temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > >  		_nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > >  		return result;
> > > >  	}
> > > >
> > > > -	if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > +	if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > >  		p_buffer += result;
> > > >  		result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > >  		req->div_len = result;
> > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > >  		req->req.actual += result;
> > > >  		i_recv_length -= result;
> > > >
> > > > -		if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > +		if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > >  			p_buffer += result;
> > > >  			i_remain_size -= result;
> > > >
> > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > >  	req->req.actual += result;
> > > >
> > > > -	if ((req->req.actual == req->req.length) ||
> > > > -	    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > +	if (req->req.actual == req->req.length ||
> > > > +	    (req->req.actual % ep->ep.maxpacket) != 0) {
> > > >  		result = 0;
> > > >  	}
> > > >
> > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > >  	i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > >
> > > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > -	    (i_buf_size  >= sizeof(u32))) {
> > > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > +	    i_buf_size  >= sizeof(u32)) {
> > > >  		nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > >  	} else {
> > > >  		i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > >  			}
> > > >  		}
> > > >  	} else {
> > > > -		if ((req->req.actual == req->req.length) ||
> > > > -		    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > +		if (req->req.actual == req->req.length ||
> > > > +		    (req->req.actual % ep->ep.maxpacket) != 0) {
> > > >  			result = 0;
> > > >  		}
> > > >  	}
> > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > >  	num = ep->epnum - 1;
> > > >
> > > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > -	    (data_size >= sizeof(u32))) {
> > > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > +	    data_size >= sizeof(u32)) {
> > > >  		nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > >  	} else {
> > > >  		data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > >  	u8		num;
> > > >  	u32		data;
> > > >
> > > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > +	if (ep_adrs == 0 || ep_adrs == 0x80)
> > > >  		return;
> > > >
> > > >  	num = (ep_adrs & 0x7F) - 1;
> > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > >  	struct nbu2ss_ep *ep;
> > > >  	struct fc_regs __iomem *preg = udc->p_regs;
> > > >
> > > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > +	if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > >  		if (bstall) {
> > > >  			/* Set STALL */
> > > >  			_nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > >  	u8	ep_adrs;
> > > >  	int	result = -EOPNOTSUPP;
> > > >
> > > > -	if ((udc->ctrl.wLength != 0x0000) ||
> > > > -	    (direction != USB_DIR_OUT)) {
> > > > +	if (udc->ctrl.wLength != 0x0000 ||
> > > > +	    direction != USB_DIR_OUT) {
> > > >  		return -EINVAL;
> > > >  	}
> > > >
> > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > >  	u8	ep_adrs;
> > > >  	int	result = -EINVAL;
> > > >
> > > > -	if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > +	if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > >  		return result;
> > > >
> > > >  	length =
> > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > >  	int		result = 0;
> > > >  	u32		wValue = le16_to_cpu(udc->ctrl.wValue);
> > > >
> > > > -	if ((udc->ctrl.bRequestType != 0x00)	||
> > > > -	    (udc->ctrl.wIndex != 0x0000)	||
> > > > -		(udc->ctrl.wLength != 0x0000)) {
> > > > +	if (udc->ctrl.bRequestType != 0x00	||
> > > > +	    udc->ctrl.wIndex != 0x0000		||
> > > > +		udc->ctrl.wLength != 0x0000) {
> > > >  		return -EINVAL;
> > > >  	}
> > > >
> > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > >  {
> > > >  	u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > >
> > > > -	if ((udc->ctrl.wIndex != 0x0000)	||
> > > > -	    (udc->ctrl.wLength != 0x0000)	||
> > > > -		(udc->ctrl.bRequestType != 0x00)) {
> > > > +	if (udc->ctrl.wIndex != 0x0000	||
> > > > +	    udc->ctrl.wLength != 0x0000	||
> > > > +		udc->ctrl.bRequestType != 0x00) {
> > > >  		return -EINVAL;
> > > >  	}
> > > >
> > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > >  	}
> > > >
> > > >  #ifdef USE_DMA
> > > > -	if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > -	    (req->req.dma != 0))
> > > > +	if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > +	    req->req.dma != 0)
> > > >  		_nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > >  #endif
> > > >
> > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > >  		mpkt = ep->ep.maxpacket;
> > > >  		size = preq->actual % mpkt;
> > > >  		if (size > 0) {
> > > > -			if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > +			if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > >  				_nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > >  		} else {
> > > >  			_nbu2ss_epn_in_int(udc, ep, req);
> > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > >  	}
> > > >
> > > >  	ep_type = usb_endpoint_type(desc);
> > > > -	if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > -	    (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > +	if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > +	    ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > >  		pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > >  		return -EINVAL;
> > > >  	}
> > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > >  	if (udc->vbus_active == 0)
> > > >  		return -ESHUTDOWN;
> > > >
> > > > -	if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > +	if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > >  		dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > >  		return -ESHUTDOWN;
> > > >  	}
> > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > >  		}
> > > >  	}
> > > >
> > > > -	if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > -	    (req->req.dma != 0))
> > > > +	if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > +	    req->req.dma != 0)
> > > >  		_nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > >  #endif
> > > >
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
> >

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16152E541;
	Mon, 16 Oct 2023 13:23:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=inria.fr
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=inria.fr
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=inria.fr header.i=@inria.fr header.b="RD9biKN9"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=jYUclKbON4FEl6Fshh956NwYxG/nDlikJfrgRNEy6f8=;
  b=RD9biKN9cW+MWfwRZngR/+ToWKdy2yXCGdNverclR5K2jeFfCwY1zgtx
   +1bX4mMZoDSXc/TMyNENBTl5y2msmDDWvBQ3vwBqoVlr9nleXliP8xRcw
   NL9v2QJ1JeEVpxofYYWwsY9KVTN7WyDZZ79sD321PBQ1hIGWJk/H3zupa
   4=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="6.03,229,1694728800"; 
   d="scan'208";a="131475603"
Received: from dhcp-138-246-3-50.dynamic.eduroam.mwn.de (HELO hadrien) ([138.246.3.50])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 15:23:57 +0200
Date: Mon, 16 Oct 2023 15:23:57 +0200 (CEST)
From: Julia Lawall <julia.lawall@inria.fr>
To: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
cc: outreachy@lists.linux.dev, linux-staging@lists.linux.dev, 
    linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: your mail
In-Reply-To: <ZS0vwhwxUkI6n8I6@gilbert-PC>
Message-ID: <e210e0cf-f470-503d-a01a-77f1d7ae4cf@inria.fr>
References: <ZS0tGLOJxUztxbKj@gilbert-PC> <3c8e9839-78f0-bb72-a195-ee4c54b68c7f@inria.fr> <ZS0vwhwxUkI6n8I6@gilbert-PC>
Precedence: bulk
X-Mailing-List: linux-staging@lists.linux.dev
List-Id: <linux-staging.lists.linux.dev>
List-Subscribe: <mailto:linux-staging+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:linux-staging+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII



On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:

> On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > > Bcc:
> > > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> > >  condition tests
> > > Reply-To:
> > > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> > >
> > > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > > >
> > > >
> > > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > > >
> > > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > > around condition tests.
> > > >
> > > > If you need to make any changes to the patch, there is no need to give the
> > > > count of the changes.  It doesn't matter if it's 47, 46, 35, etc.
> > > >
> > > > julia
> > > >
> > > Hi Julia,
> > >
> > > I added the number because I saw I similar commit on the logs that did
> > > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> >
> > OK, I still think it's pointless...  The person who looks at the commit 5
> > years from now won't care about this information.  They care about what
> > you did and why.
> >
> > julia
> >
> Ok that make sense. I will revise it. Do I send revision patch now or
> later today?

You can wait, in case there are other comments.

julia

> >
> > > > >
> > > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > > ---
> > > > >  drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > > >  1 file changed, 36 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > index eb63daaca702..e8ddd691b788 100644
> > > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > > >  			/* SET_FEATURE */
> > > > >  			recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > > >  			selector  = le16_to_cpu(p_ctrl->wValue);
> > > > > -			if ((recipient == USB_RECIP_DEVICE) &&
> > > > > -			    (selector == USB_DEVICE_TEST_MODE)) {
> > > > > +			if (recipient == USB_RECIP_DEVICE &&
> > > > > +			    selector == USB_DEVICE_TEST_MODE) {
> > > > >  				wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > > >  				test_mode = (u32)(wIndex >> 8);
> > > > >  				_nbu2ss_set_test_mode(udc, test_mode);
> > > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > >  	u32		num;
> > > > >  	u32		data;
> > > > >
> > > > > -	if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > > +	if (ep->epnum == 0 || udc->vbus_active == 0)
> > > > >  		return	-EINVAL;
> > > > >
> > > > >  	num = ep->epnum - 1;
> > > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > >  	u32		data;
> > > > >
> > > > >  	data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > > -	if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > >  		return;		/* Not Support DMA */
> > > > >
> > > > >  	num = ep->epnum - 1;
> > > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > >  		return;		/* VBUS OFF */
> > > > >
> > > > >  	data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > > -	if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > > +	if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > >  		return;		/* Not Support DMA */
> > > > >
> > > > >  	num = ep->epnum - 1;
> > > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > > >  	union usb_reg_access  temp_32;
> > > > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > -	if ((length > 0) && (length < sizeof(u32))) {
> > > > > +	if (length > 0 && length < sizeof(u32)) {
> > > > >  		temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > > >  		for (i = 0 ; i < length ; i++)
> > > > >  			p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > > >  	union usb_reg_access  temp_32;
> > > > >  	union usb_reg_access  *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > -	if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > > +	if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > > >  		for (i = 0 ; i < i_remain_size ; i++)
> > > > >  			temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > > >  		_nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > > >  		return result;
> > > > >  	}
> > > > >
> > > > > -	if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > > +	if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > > >  		p_buffer += result;
> > > > >  		result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > > >  		req->div_len = result;
> > > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > > >  		req->req.actual += result;
> > > > >  		i_recv_length -= result;
> > > > >
> > > > > -		if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > > +		if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > > >  			p_buffer += result;
> > > > >  			i_remain_size -= result;
> > > > >
> > > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > >  	req->req.actual += result;
> > > > >
> > > > > -	if ((req->req.actual == req->req.length) ||
> > > > > -	    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > +	if (req->req.actual == req->req.length ||
> > > > > +	    (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > >  		result = 0;
> > > > >  	}
> > > > >
> > > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > >  	i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > > >
> > > > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > -	    (i_buf_size  >= sizeof(u32))) {
> > > > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > +	    i_buf_size  >= sizeof(u32)) {
> > > > >  		nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > > >  	} else {
> > > > >  		i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > > >  			}
> > > > >  		}
> > > > >  	} else {
> > > > > -		if ((req->req.actual == req->req.length) ||
> > > > > -		    ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > +		if (req->req.actual == req->req.length ||
> > > > > +		    (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > >  			result = 0;
> > > > >  		}
> > > > >  	}
> > > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > >  	num = ep->epnum - 1;
> > > > >
> > > > > -	if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > -	    (data_size >= sizeof(u32))) {
> > > > > +	if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > +	    data_size >= sizeof(u32)) {
> > > > >  		nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > > >  	} else {
> > > > >  		data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > > >  	u8		num;
> > > > >  	u32		data;
> > > > >
> > > > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > > +	if (ep_adrs == 0 || ep_adrs == 0x80)
> > > > >  		return;
> > > > >
> > > > >  	num = (ep_adrs & 0x7F) - 1;
> > > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > > >  	struct nbu2ss_ep *ep;
> > > > >  	struct fc_regs __iomem *preg = udc->p_regs;
> > > > >
> > > > > -	if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > > +	if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > > >  		if (bstall) {
> > > > >  			/* Set STALL */
> > > > >  			_nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > > >  	u8	ep_adrs;
> > > > >  	int	result = -EOPNOTSUPP;
> > > > >
> > > > > -	if ((udc->ctrl.wLength != 0x0000) ||
> > > > > -	    (direction != USB_DIR_OUT)) {
> > > > > +	if (udc->ctrl.wLength != 0x0000 ||
> > > > > +	    direction != USB_DIR_OUT) {
> > > > >  		return -EINVAL;
> > > > >  	}
> > > > >
> > > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > > >  	u8	ep_adrs;
> > > > >  	int	result = -EINVAL;
> > > > >
> > > > > -	if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > > +	if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > > >  		return result;
> > > > >
> > > > >  	length =
> > > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > > >  	int		result = 0;
> > > > >  	u32		wValue = le16_to_cpu(udc->ctrl.wValue);
> > > > >
> > > > > -	if ((udc->ctrl.bRequestType != 0x00)	||
> > > > > -	    (udc->ctrl.wIndex != 0x0000)	||
> > > > > -		(udc->ctrl.wLength != 0x0000)) {
> > > > > +	if (udc->ctrl.bRequestType != 0x00	||
> > > > > +	    udc->ctrl.wIndex != 0x0000		||
> > > > > +		udc->ctrl.wLength != 0x0000) {
> > > > >  		return -EINVAL;
> > > > >  	}
> > > > >
> > > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > > >  {
> > > > >  	u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > > >
> > > > > -	if ((udc->ctrl.wIndex != 0x0000)	||
> > > > > -	    (udc->ctrl.wLength != 0x0000)	||
> > > > > -		(udc->ctrl.bRequestType != 0x00)) {
> > > > > +	if (udc->ctrl.wIndex != 0x0000	||
> > > > > +	    udc->ctrl.wLength != 0x0000	||
> > > > > +		udc->ctrl.bRequestType != 0x00) {
> > > > >  		return -EINVAL;
> > > > >  	}
> > > > >
> > > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > > >  	}
> > > > >
> > > > >  #ifdef USE_DMA
> > > > > -	if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > > -	    (req->req.dma != 0))
> > > > > +	if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > > +	    req->req.dma != 0)
> > > > >  		_nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > > >  #endif
> > > > >
> > > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > > >  		mpkt = ep->ep.maxpacket;
> > > > >  		size = preq->actual % mpkt;
> > > > >  		if (size > 0) {
> > > > > -			if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > > +			if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > > >  				_nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > > >  		} else {
> > > > >  			_nbu2ss_epn_in_int(udc, ep, req);
> > > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > >  	}
> > > > >
> > > > >  	ep_type = usb_endpoint_type(desc);
> > > > > -	if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > > -	    (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > > +	if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > > +	    ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > > >  		pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > > >  		return -EINVAL;
> > > > >  	}
> > > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > >  	if (udc->vbus_active == 0)
> > > > >  		return -ESHUTDOWN;
> > > > >
> > > > > -	if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > > +	if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > > >  		dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > > >  		return -ESHUTDOWN;
> > > > >  	}
> > > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > > >  		}
> > > > >  	}
> > > > >
> > > > > -	if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > > -	    (req->req.dma != 0))
> > > > > +	if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > > +	    req->req.dma != 0)
> > > > >  		_nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > > >  #endif
> > > > >
> > > > > --
> > > > > 2.34.1
> > > > >
> > > > >
> > > > >
> > >
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Message-ID: <4F38DA79.2040803@suse.cz>
Date: Mon, 13 Feb 2012 10:40:09 +0100
From: Jiri Slaby <jslaby@suse.cz>
MIME-Version: 1.0
References: <1329006070-4275-1-git-send-email-richard@nod.at> <20120212010211.GN23916@ZenIV.linux.org.uk> <4F37B34F.1040307@suse.cz> <20120212190611.GP23916@ZenIV.linux.org.uk>
In-Reply-To: <20120212190611.GP23916@ZenIV.linux.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Jiri Slaby <jirislaby@gmail.com>, Richard Weinberger <richard@nod.at>, linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On 02/12/2012 08:06 PM, Al Viro wrote:
> Yecchhh...  If I'm reading (and grepping) it right, there are only two
> non-default instance of tty_operations ->shutdown() - pty and vt ones.
> Lovely...  And while we are at it, vt instance is definitely not safe
> from interrupts - calls console_lock().  Not that it was relevant in
> this case...

Thanks for looking into that. I was too lazy to do that on Sunday.

You're right that it may cause problems. Fortunately vt doesn't refcount
ttys. Hence con_shutdown can be called only from release_tty (close
path) in the user context.

Adding to my TODO list, unless somebody beats me to fix it.

thanks,
-- 
js
suse labs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Message-ID: <4F38D4C5.9080907@suse.cz>
Date: Mon, 13 Feb 2012 10:15:49 +0100
From: Jiri Slaby <jslaby@suse.cz>
MIME-Version: 1.0
References: <1329006070-4275-1-git-send-email-richard@nod.at> <20120212191134.GQ23916@ZenIV.linux.org.uk>
In-Reply-To: <20120212191134.GQ23916@ZenIV.linux.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Weinberger <richard@nod.at>, linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On 02/12/2012 08:11 PM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
> 
>> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>>  {
>>  	struct chan *chan = data;
>>  	struct line *line = chan->line;
>> -	struct tty_struct *tty = line->tty;
>> +	struct tty_struct *tty = tty_port_tty_get(&line->port);
>>  	int err;
>>  
>>  	/*
>> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>>  	spin_lock(&line->lock);
>>  	err = flush_buffer(line);
>>  	if (err == 0) {
>> +		tty_kref_put(tty);
>> +
>> +		spin_unlock(&line->lock);
>>  		return IRQ_NONE;
>>  	} else if (err < 0) {
>>  		line->head = line->buffer;
>> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>>  		return IRQ_NONE;
>>  
>>  	tty_wakeup(tty);
>> +	tty_kref_put(tty);
>>  	return IRQ_HANDLED;
>>  }
> 
> That, BTW, smells ugly.  Note that return before the last one has no
> tty_kref_put() for a very good reason - it's under if (!tty).  And
> just as line->tty, port->tty can become NULL, so tty_port_tty_get()
> can, indeed, return NULL here.  Which makes the first tty_kref_put()
> oopsable...

Nope, it is allowed to call tty_kref_put(NULL).

regards,
-- 
js
suse labs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Date: Sun, 12 Feb 2012 19:11:34 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
Message-ID: <20120212191134.GQ23916@ZenIV.linux.org.uk>
References: <1329006070-4275-1-git-send-email-richard@nod.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1329006070-4275-1-git-send-email-richard@nod.at>
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:

> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>  {
>  	struct chan *chan = data;
>  	struct line *line = chan->line;
> -	struct tty_struct *tty = line->tty;
> +	struct tty_struct *tty = tty_port_tty_get(&line->port);
>  	int err;
>  
>  	/*
> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>  	spin_lock(&line->lock);
>  	err = flush_buffer(line);
>  	if (err == 0) {
> +		tty_kref_put(tty);
> +
> +		spin_unlock(&line->lock);
>  		return IRQ_NONE;
>  	} else if (err < 0) {
>  		line->head = line->buffer;
> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>  		return IRQ_NONE;
>  
>  	tty_wakeup(tty);
> +	tty_kref_put(tty);
>  	return IRQ_HANDLED;
>  }

That, BTW, smells ugly.  Note that return before the last one has no
tty_kref_put() for a very good reason - it's under if (!tty).  And
just as line->tty, port->tty can become NULL, so tty_port_tty_get()
can, indeed, return NULL here.  Which makes the first tty_kref_put()
oopsable...

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Date: Sun, 12 Feb 2012 19:06:11 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
Message-ID: <20120212190611.GP23916@ZenIV.linux.org.uk>
References: <1329006070-4275-1-git-send-email-richard@nod.at>
 <20120212010211.GN23916@ZenIV.linux.org.uk>
 <4F37B34F.1040307@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F37B34F.1040307@suse.cz>
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Jiri Slaby <jslaby@suse.cz>
Cc: Richard Weinberger <richard@nod.at>, linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org, Jiri Slaby <jirislaby@gmail.com>
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On Sun, Feb 12, 2012 at 01:40:47PM +0100, Jiri Slaby wrote:
> > Is tty_kref_put() safe in interrupt?  Here it seems to be OK, but in other
> > callers...  More or less at random: drivers/tty/serial/lantiq.c has it
> > called from lqasc_rx_int().  It seems to be possible to have it end up
> > calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> > Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> > we have it called from.  Alan?
> 
> I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
> does something tricky). In the driver you mention, this is uart_ops,
> called from tty_port_operations' ->shutdown. And that's a different from
> tty_operations' ->shutdown.
> 
> Yes, there are:
> * tty->ops
> * tty_port->ops
> * uart_port->ops
> 
> uart_port->ops->shutdown is supposed to tear down interrupts like in
> lantiq.c. It is called from tty_port->ops->shutdown. And that one is
> allowed to be called only from user context (tty->ops->close and
> tty->ops->hangup).

Yecchhh...  If I'm reading (and grepping) it right, there are only two
non-default instance of tty_operations ->shutdown() - pty and vt ones.
Lovely...  And while we are at it, vt instance is definitely not safe
from interrupts - calls console_lock().  Not that it was relevant in
this case...

It's probably too late in this case, but I would've called that method
->sync_cleanup().  Assuming I'm not misreading its intent and history...

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Message-ID: <4F37B34F.1040307@suse.cz>
Date: Sun, 12 Feb 2012 13:40:47 +0100
From: Jiri Slaby <jslaby@suse.cz>
MIME-Version: 1.0
References: <1329006070-4275-1-git-send-email-richard@nod.at> <20120212010211.GN23916@ZenIV.linux.org.uk>
In-Reply-To: <20120212010211.GN23916@ZenIV.linux.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Weinberger <richard@nod.at>, linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org, Jiri Slaby <jirislaby@gmail.com>
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On 02/12/2012 02:02 AM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
>> +++ b/arch/um/drivers/line.c
>> @@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
>>  {
>>  	struct chan *chan = data;
>>  	struct line *line = chan->line;
>> +	struct tty_struct *tty;
>> +
>> +	if (line) {
>> +		tty = tty_port_tty_get(&line->port);
>> +		chan_interrupt(&line->chan_list, &line->task, tty, irq);
>> +		tty_kref_put(tty);
>> +	}
>>  
>> -	if (line)
>> -		chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
>>  	return IRQ_HANDLED;
>>  }
> 
> Is tty_kref_put() safe in interrupt?  Here it seems to be OK, but in other
> callers...  More or less at random: drivers/tty/serial/lantiq.c has it
> called from lqasc_rx_int().  It seems to be possible to have it end up
> calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> we have it called from.  Alan?

I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
does something tricky). In the driver you mention, this is uart_ops,
called from tty_port_operations' ->shutdown. And that's a different from
tty_operations' ->shutdown.

Yes, there are:
* tty->ops
* tty_port->ops
* uart_port->ops

uart_port->ops->shutdown is supposed to tear down interrupts like in
lantiq.c. It is called from tty_port->ops->shutdown. And that one is
allowed to be called only from user context (tty->ops->close and
tty->ops->hangup).

thanks,
-- 
js
suse labs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Date: Sun, 12 Feb 2012 01:25:03 +0100 (CET)
From: Jesper Juhl <jj@chaosbits.net>
In-Reply-To: <1329006070-4275-1-git-send-email-richard@nod.at>
Message-ID: <alpine.LNX.2.00.1202120123110.7100@swampdragon.chaosbits.net>
References: <1329006070-4275-1-git-send-email-richard@nod.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Subject: Re: your mail
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org
List-ID: <user-mode-linux-devel.lists.sourceforge.net>

On Sun, 12 Feb 2012, Richard Weinberger wrote:

> Can you please review this patch?
> 

A subject on the mail along with a description of the patch would make 
that a great deal easier...

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=yDBg=6Z=vger.kernel.org=linux-usb-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 20631C47255
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 11:35:20 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 0A250214DB
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 11:35:20 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729745AbgEKLfN (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Mon, 11 May 2020 07:35:13 -0400
Received: from mga02.intel.com ([134.134.136.20]:42750 "EHLO mga02.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1729610AbgEKLfL (ORCPT <rfc822;linux-usb@vger.kernel.org>);
        Mon, 11 May 2020 07:35:11 -0400
IronPort-SDR: vZROyOj1WAPPXxCtEYkeit6DKDpqyW8NCR7T3IlyQz3IqkvuyoyHV8bRlDtSFJZLuolcS85POh
 Y8Cvu8HDExEA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
  by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2020 04:35:10 -0700
IronPort-SDR: pL1SsiTAJyIBF/Qu6mEw90bEMYOwWcUPILyyajrHPk3Au1WGiusSXB3OnViGL9gXuFf07HReZH
 RkiBBWIfVYxQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,379,1583222400"; 
   d="scan'208";a="371194061"
Received: from kuha.fi.intel.com ([10.237.72.162])
  by fmsmga001.fm.intel.com with SMTP; 11 May 2020 04:35:07 -0700
Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Mon, 11 May 2020 14:35:06 +0300
Date:   Mon, 11 May 2020 14:35:06 +0300
From:   Heikki Krogerus <heikki.krogerus@linux.intel.com>
To:     jakub@bilan.me, Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     linux-usb@vger.kernel.org
Subject: Re: your mail
Message-ID: <20200511113506.GB2062175@kuha.fi.intel.com>
References: <526351589195104@mail.yandex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <526351589195104@mail.yandex.com>
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

+Andy

Adding also the linux-usb mailing list.

On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> with cpu interrups causing issues with deeper CPU sleep and increased power
> usage. Also load is always 1 even if machine has nothing to do.
>  
> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> device is related with USB and according to datasheet it's "USB Interface IC USB
> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> nothing connected to NUC except power plug and ethernet cable.
>  
> Screenshots: https://imgur.com/a/uw9NDCi
>  
> How to solve this issue? Could you help me?

My guess is that the IRQ resource is not correct for the PD
controller causing you to see irq flood.

The problem is that the ACPI device entry (the node) on this platform
has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
single ACPI device entry can represent up to 4 USB PD controllers. The
problem is that there is no way to know which IRQ resource belongs to
which I2CSerialBus resource :-(.

Andy, this is one of those multi-instantiate I2C slave devices with
HID INT3515.

The only solution I can think of is that we start maintaining DMI
quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
supply the correct i2c to irq resource mapping for every platform
that has this device(s).

> Kernel version:
>  
> Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>  
> Bios version:
> FNCML357 Version: 0039 Date: 3/12/2020
> -- 
> Best regards
> Jakub Bilan

thanks,

-- 
heikki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=yDBg=6Z=vger.kernel.org=linux-usb-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id DFA2AC47255
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 11:44:34 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id BB98220735
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 11:44:34 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Z6ea+Aqr"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729600AbgEKLo2 (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Mon, 11 May 2020 07:44:28 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41754 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL)
        by vger.kernel.org with ESMTP id S1729475AbgEKLo2 (ORCPT
        <rfc822;linux-usb@vger.kernel.org>); Mon, 11 May 2020 07:44:28 -0400
Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9214C061A0C;
        Mon, 11 May 2020 04:44:27 -0700 (PDT)
Received: by mail-pj1-x1042.google.com with SMTP id h12so7330478pjz.1;
        Mon, 11 May 2020 04:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=r9UHrXsbrgOr++DxzjQkfPs/L0KfhL6f2GKrka/MgsQ=;
        b=Z6ea+AqrA15W8CEParO5DzvhULrixOvrlDhhntNfp7pfApj/kW0fpzvn1n3LtvB1zI
         spYr4z+DbR9sxMV9ACps0wxuOOiEEP934ya9yiKudNTZt2L15mIakLKe+R/S0eG3G/ON
         jid3sbTFyZKBPsZoTDYYPeK9VWF+xt+4t6zmnMaj1eG0kSsPTNOvNZtKNhG4nkwMULr9
         j0NWrZWatWBoQQg2zsRbLEJd0AN49DKVOKdbO58NF9GqkkrlfEFdUV9F6lj1bvLxvBzK
         IKgKdle7WHNml1ApZr5U4zsbiQTvBvp2y93x5RMTQ893jaebjJdf3WAgPTYJEMjQmRFt
         AKCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=r9UHrXsbrgOr++DxzjQkfPs/L0KfhL6f2GKrka/MgsQ=;
        b=DZh64x09BPy8D1qLJG8qW4j2bCN3IR7OomvbB2uEguCauxqbKtOALw8RxPL5HphudI
         T2/1U4H9F65h1rJBVeWDAa6XxiTQXSTihc0LBYk3xO4SNuK6K2sa3Hwa0+//23cJSHLW
         xP5jrPW/3jaWCuDNJDUZmqpuomCOaNBWspsbEMrgc5Z6K50xTE3EL8C6oJrqolP1frun
         thLAq174eMga1FD9pFouwLGjFYTkJghLPG5/fJo/RFmPnHX2s1RM2A/O2ACNkF3i3QMr
         HQmj34PxlNnn7oRBPSGdmeRpLQNTMPzuVxDmkN6ej2JklRUyDW1bZv6K7ULMO0eEwsM3
         P6gg==
X-Gm-Message-State: AGi0Pub2HwW1oH065r3UGwnSAhI+Y73yfrQNXB3hbMexxbdT3Ztt0JbA
        Wea6Wkg6yCR0iG1bZqpVQ/8IG8ugXQMSTv2CrTrh8oQV
X-Google-Smtp-Source: APiQypJ76WfhXKVe0jpzzv3M5zg9WFaUDcMTJhY6CORp0ArZGOL6KutM8Kb5dcxhU62plxivfOBMHI1oyuPen/Xos40=
X-Received: by 2002:a17:90b:94a:: with SMTP id dw10mr22536348pjb.228.1589197467380;
 Mon, 11 May 2020 04:44:27 -0700 (PDT)
MIME-Version: 1.0
References: <526351589195104@mail.yandex.com> <20200511113506.GB2062175@kuha.fi.intel.com>
In-Reply-To: <20200511113506.GB2062175@kuha.fi.intel.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 11 May 2020 14:44:20 +0300
Message-ID: <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
Subject: Re: your mail
To:     Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Hans de Goede <hdegoede@redhat.com>
Cc:     jakub@bilan.me,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        USB <linux-usb@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

+Cc: Hans

On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> +Andy
>
> Adding also the linux-usb mailing list.
>
> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> > Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> > with cpu interrups causing issues with deeper CPU sleep and increased power
> > usage. Also load is always 1 even if machine has nothing to do.
> >
> > I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> > device is related with USB and according to datasheet it's "USB Interface IC USB
> > Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> > nothing connected to NUC except power plug and ethernet cable.
> >
> > Screenshots: https://imgur.com/a/uw9NDCi
> >
> > How to solve this issue? Could you help me?
>
> My guess is that the IRQ resource is not correct for the PD
> controller causing you to see irq flood.
>
> The problem is that the ACPI device entry (the node) on this platform
> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
> single ACPI device entry can represent up to 4 USB PD controllers. The
> problem is that there is no way to know which IRQ resource belongs to
> which I2CSerialBus resource :-(.
>
> Andy, this is one of those multi-instantiate I2C slave devices with
> HID INT3515.
>
> The only solution I can think of is that we start maintaining DMI
> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
> supply the correct i2c to irq resource mapping for every platform
> that has this device(s).

I would rather disable them and issue a firmware bug.
Vendors, including us, should do something sane about this.

> > Kernel version:
> >
> > Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > Bios version:
> > FNCML357 Version: 0039 Date: 3/12/2020

-- 
With Best Regards,
Andy Shevchenko

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=yDBg=6Z=vger.kernel.org=linux-usb-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 955F5C47255
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 12:29:38 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 6921B207FF
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 12:29:38 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="arjPJlm2"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729897AbgEKM3c (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Mon, 11 May 2020 08:29:32 -0400
Received: from us-smtp-2.mimecast.com ([207.211.31.81]:23553 "EHLO
        us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1728084AbgEKM3b (ORCPT
        <rfc822;linux-usb@vger.kernel.org>); Mon, 11 May 2020 08:29:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
        s=mimecast20190719; t=1589200170;
        h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
         to:to:cc:cc:mime-version:mime-version:content-type:content-type:
         content-transfer-encoding:content-transfer-encoding:
         in-reply-to:in-reply-to:references:references;
        bh=C6bkmx2Au9aJV/eJKVFmnYa+SP3QUXOVqL+LmgTI3ts=;
        b=arjPJlm2grMfowNYYjITSyIm1MVGJbA0sFCoq3AQcH7RQndtgTX4Z8iDNsc3Pgq2t2InYY
        6YEuz4437XDYmqEJtiBCddSrsn69uqyMYGUyc2g1sSpHcUDnWoj4KLsxK+kbQmdJjGpBCj
        tdrrBqNjTmCYtjGmy1rUGiFPF8GgPS8=
Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com
 [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-391--eGssgXDPv6sSi-pUspLvA-1; Mon, 11 May 2020 08:29:27 -0400
X-MC-Unique: -eGssgXDPv6sSi-pUspLvA-1
Received: by mail-wr1-f71.google.com with SMTP id g10so5172194wrr.10
        for <linux-usb@vger.kernel.org>; Mon, 11 May 2020 05:29:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:to:cc:references:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=C6bkmx2Au9aJV/eJKVFmnYa+SP3QUXOVqL+LmgTI3ts=;
        b=N8ZDhkgE836s8VdIDWocbUVAL5um0iP9Q7CTzsmhM+DrH/fqDe8dVtLW0DJYwln3dI
         kiVOUAGIeKM4xeJpv8fs5+fA9+EcRKSdKvz4CMjw4O2/5wd/uDMuFUz2XrHRTAJRiOdm
         9N/p1w8Qj+xtNlfc7/e+sUqLPjidUlLorCANzrfEil40yHqiqQBBRbXw2hWv17gHyEzo
         Ze0WliSC4l5LoH/uoQYZeUOATr4KYyt/F3eYAAbX0PDpKxKq4Sb0Pyrs8s98vh4fUELJ
         jn/VU6vdtwbiG/0dqrC8nVs2ACvIGAOA0LPl/S9puIpIW69TreFlTS3/GebmOC9thoHt
         Uzzw==
X-Gm-Message-State: AGi0PuaAagnGgAaovJ32xO9KwTgY62kWagSx5FZrQtmG0BbJ4W5Aa4Mm
        WuQ+dPGs3kkoVgwmQ6JrRC0vc3fKUBR/oWClYUBkjgnBy/Cp27EW/I2xPY14W9cOWcnXy6UaLWB
        wxG+/NTSiVGDt5uZqNRqx
X-Received: by 2002:a5d:55c5:: with SMTP id i5mr13014988wrw.402.1589200166325;
        Mon, 11 May 2020 05:29:26 -0700 (PDT)
X-Google-Smtp-Source: APiQypKe4b0dRV+F1Cr815EBSgnwnsGVHu87+SL20WjD6O61pau0W53Seo7zP9NaelOI+yQBG8GfIg==
X-Received: by 2002:a5d:55c5:: with SMTP id i5mr13014969wrw.402.1589200166059;
        Mon, 11 May 2020 05:29:26 -0700 (PDT)
Received: from x1.localdomain (2001-1c00-0c0c-fe00-d2ea-f29d-118b-24dc.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:d2ea:f29d:118b:24dc])
        by smtp.gmail.com with ESMTPSA id h74sm18347920wrh.76.2020.05.11.05.29.25
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 11 May 2020 05:29:25 -0700 (PDT)
Subject: Re: your mail
To:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc:     jakub@bilan.me,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        USB <linux-usb@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>
References: <526351589195104@mail.yandex.com>
 <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
Date:   Mon, 11 May 2020 14:29:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

Hi,

On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> +Cc: Hans

Thank you, I'm afraid that I do not have much of value
to add here, Heikki knows these systems (with an INT3515 device)
a lot better then I do.

> On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
>>
>> +Andy
>>
>> Adding also the linux-usb mailing list.
>>
>> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
>>> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
>>> with cpu interrups causing issues with deeper CPU sleep and increased power
>>> usage. Also load is always 1 even if machine has nothing to do.
>>>
>>> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
>>> device is related with USB and according to datasheet it's "USB Interface IC USB
>>> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
>>> nothing connected to NUC except power plug and ethernet cable.
>>>
>>> Screenshots: https://imgur.com/a/uw9NDCi
>>>
>>> How to solve this issue? Could you help me?
>>
>> My guess is that the IRQ resource is not correct for the PD
>> controller causing you to see irq flood.
>>
>> The problem is that the ACPI device entry (the node) on this platform
>> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
>> single ACPI device entry can represent up to 4 USB PD controllers. The
>> problem is that there is no way to know which IRQ resource belongs to
>> which I2CSerialBus resource :-(.
>>
>> Andy, this is one of those multi-instantiate I2C slave devices with
>> HID INT3515.
>>
>> The only solution I can think of is that we start maintaining DMI
>> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
>> supply the correct i2c to irq resource mapping for every platform
>> that has this device(s).
> 
> I would rather disable them and issue a firmware bug.
> Vendors, including us, should do something sane about this.

I have to partially disagree here. I agree that for future hardware
versions the firmware team of those devices should offer a saner
interface. But for the current hardware gen I guess we are stuck
with this and having a DMI table for popular models (well any model
a Linux user is willing to submit a quirk for) is better then simply
not having things working under Linux.

I do wonder what Windows does here though. Perhaps the INT3513 device
has some ACPI methods to query for more info, like how many Type-C
controllers there actually are?

Regards,

Hans


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=yDBg=6Z=vger.kernel.org=linux-usb-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id C2F82C47255
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 13:40:19 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 927C6206B7
	for <linux-usb@archiver.kernel.org>; Mon, 11 May 2020 13:40:19 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tJUFehzs"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729546AbgEKNkN (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Mon, 11 May 2020 09:40:13 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59972 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL)
        by vger.kernel.org with ESMTP id S1726115AbgEKNkN (ORCPT
        <rfc822;linux-usb@vger.kernel.org>); Mon, 11 May 2020 09:40:13 -0400
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21FB9C061A0C;
        Mon, 11 May 2020 06:40:13 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id u5so1970612pgn.5;
        Mon, 11 May 2020 06:40:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=4dSKfo4BB8XKhh+B2SEjxAoByaA8GenGemeaNW0Wgtk=;
        b=tJUFehzsx9NE8C3Nfpwlix9zA/6zXpqSXQYSvSF/Ej63HHRVPTGniQaWJNTjEkywuK
         H6ERbyt5iYUbPfYTQe4VMvE08Wtdv3Q7B/pekO/JGiidWawx8oZVuEYgLjvyiG3iKPNl
         zFfeGEdCyc/u9qR8QKN4dbVBkXZJz5y6qkD8AvAHINYaPl8GmMPbguKUKXcXuNTax/Ht
         Gf7ygazBTt5nz8rFfa+jH66TBhMJlL/px9tHyvQhS5TW5TBZcwQCz0pDqUcA2Ne+i7aL
         /43TGzR/nEWmwy54D4H+uqzLChcHVXFDtUCr1HW1iDrDEMfcwkRcZLkN81QsY8itPcIh
         YMsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=4dSKfo4BB8XKhh+B2SEjxAoByaA8GenGemeaNW0Wgtk=;
        b=X3/XKDduMV0OPHSJGMoga4eStDOi8bDA2oHE2a+W3gf923LWCH8/s7OpTRW7k/Z9m2
         EHRwp/U467U5cSOkcYH2K3UXSAOkoK9ZduJqxDI+TYN3gxPZVs5XG7eyTm+ABnQ4M5GM
         KuTPuvdc7I3uN6mxkMmN3mMPpQzERclBdaHCjjqDm+5flLSQjReQsjfNIF94eQYsxUFK
         NqYCK7yqF+sJotqMTv7Bl9s2WVYZKQaXrIt/KazpialQblE7EWQJtdth/bMGi2WDVtIE
         1Ri4+x6t3RGZTeV/uKoPJB//0m6kc9YQwrU0TSWQdMRXBT4PpRA30giUDmluWh7GbgeX
         ZvKA==
X-Gm-Message-State: AGi0PuZ/cJaEMawAGdSvjfJ1QhQZ4aYgZabHVDSH6KAAFwG5MKcf5e77
        lXz4L4odwYtbQx/MTC0MaQ92U2RQssv+3fmoOwY=
X-Google-Smtp-Source: APiQypJNu08YGox6J7Brmn/GRAXX6e4vbSjZ02oGKZ/tcJXxW/ZoFrpsbwsCZZ1AibyOYf78YMLTFqRa+WUgBbx3NOQ=
X-Received: by 2002:a63:1d4:: with SMTP id 203mr14142201pgb.74.1589204412529;
 Mon, 11 May 2020 06:40:12 -0700 (PDT)
MIME-Version: 1.0
References: <526351589195104@mail.yandex.com> <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com> <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
In-Reply-To: <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 11 May 2020 16:40:05 +0300
Message-ID: <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw@mail.gmail.com>
Subject: Re: your mail
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Heikki Krogerus <heikki.krogerus@linux.intel.com>, jakub@bilan.me,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        USB <linux-usb@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 5/11/20 1:44 PM, Andy Shevchenko wrote:

...

> > I would rather disable them and issue a firmware bug.
> > Vendors, including us, should do something sane about this.
>
> I have to partially disagree here. I agree that for future hardware
> versions the firmware team of those devices should offer a saner
> interface. But for the current hardware gen I guess we are stuck
> with this and having a DMI table for popular models (well any model
> a Linux user is willing to submit a quirk for) is better then simply
> not having things working under Linux.
>
> I do wonder what Windows does here though. Perhaps the INT3513 device
> has some ACPI methods to query for more info, like how many Type-C
> controllers there actually are?

I think they do silly things there in usual obscure MS way, i.e.
hardcoding everything in the driver per platform.
That's why I'm really disappointed how things are going on.

-- 
With Best Regards,
Andy Shevchenko

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=lI7K=7A=vger.kernel.org=linux-usb-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 18C14C433DF
	for <linux-usb@archiver.kernel.org>; Mon, 18 May 2020 13:35:42 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id E4E092065F
	for <linux-usb@archiver.kernel.org>; Mon, 18 May 2020 13:35:41 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1727995AbgERNff (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Mon, 18 May 2020 09:35:35 -0400
Received: from mga18.intel.com ([134.134.136.126]:64625 "EHLO mga18.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726775AbgERNff (ORCPT <rfc822;linux-usb@vger.kernel.org>);
        Mon, 18 May 2020 09:35:35 -0400
IronPort-SDR: BgxX+mo4GwtS0LRt7jon4Dkdii9FcyFcUJVDNGr/Ix5r8beM0gFKJSsQW6ZqDTwZcK8Lqwja6e
 ng1WJBy3ILKA==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
  by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2020 06:35:34 -0700
IronPort-SDR: b+0BUGM31BW8JI4QsMPM5wO6d+1unXO1fRR8+5S0gjFWPJdYpJNl7gRJ1KWd2kE7x5B29JXV+2
 vfc6OBwF7p+Q==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,407,1583222400"; 
   d="scan'208";a="373390387"
Received: from kuha.fi.intel.com ([10.237.72.162])
  by fmsmga001.fm.intel.com with SMTP; 18 May 2020 06:35:31 -0700
Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Mon, 18 May 2020 16:35:30 +0300
Date:   Mon, 18 May 2020 16:35:30 +0300
From:   Heikki Krogerus <heikki.krogerus@linux.intel.com>
To:     jakub@bilan.me
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        USB <linux-usb@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20200518133530.GB1298122@kuha.fi.intel.com>
References: <526351589195104@mail.yandex.com>
 <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
 <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
 <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw@mail.gmail.com>
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

Hi Jakub,

On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote:
> On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> > On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> 
> ...
> 
> > > I would rather disable them and issue a firmware bug.
> > > Vendors, including us, should do something sane about this.
> >
> > I have to partially disagree here. I agree that for future hardware
> > versions the firmware team of those devices should offer a saner
> > interface. But for the current hardware gen I guess we are stuck
> > with this and having a DMI table for popular models (well any model
> > a Linux user is willing to submit a quirk for) is better then simply
> > not having things working under Linux.
> >
> > I do wonder what Windows does here though. Perhaps the INT3513 device
> > has some ACPI methods to query for more info, like how many Type-C
> > controllers there actually are?
> 
> I think they do silly things there in usual obscure MS way, i.e.
> hardcoding everything in the driver per platform.
> That's why I'm really disappointed how things are going on.

I've been trying to figure out which exact NUC10i3 your NUC is? I
can't find a NUC10i3 that uses Comet Lake -S?

If your NUC isn't actually "-S" variant, then the ACPI device entry
with HID INT3515 should return 0 from its _STA method.

But can you please share the full name of your board (like NUC10i3FNH
or something like that - should read on the bottom of the device).
Also, dmesg output would be useful.

thanks,

-- 
heikki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xfs-bounce@oss.sgi.com>
Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Oct 2006 03:07:55 -0700 (PDT)
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29])
	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k9NA7gaG014943
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2006 03:07:43 -0700
Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202])
	by cuda.sgi.com (Spam Firewall) with SMTP id 0DBD7D1A23CD
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2006 02:02:22 -0700 (PDT)
Date: Mon, 23 Oct 2006 02:02:19 -0700
From: Chris Wedgwood <cw@f00f.org>
Subject: Re: your mail
Message-ID: <20061023090219.GA18714@tuatara.stupidest.org>
References: <D3E576A1A7C7134694A0DDA7C2CA4B884C3985@hyd-mail2.bbnet.ad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D3E576A1A7C7134694A0DDA7C2CA4B884C3985@hyd-mail2.bbnet.ad>
Sender: xfs-bounce@oss.sgi.com
Errors-to: xfs-bounce@oss.sgi.com
List-Id: xfs
To: Chakka Satish Kumar <ChakkaSatish.Kumar@conexant.com>
Cc: linux-xfs@oss.sgi.com

On Mon, Oct 23, 2006 at 12:47:20PM +0530, Chakka Satish Kumar wrote:

> I formatted a partition of size 5GB with xfs block size=16K

you can't use a block size large than your machines page size, so you
probably want to leave it at 4K (the default in most cases)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xfs-bounces@oss.sgi.com>
Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29])
	by oss.sgi.com (Postfix) with ESMTP id 8827B7F51
	for <xfs@oss.sgi.com>; Sat, 13 Jun 2015 17:39:29 -0500 (CDT)
Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11])
	by relay2.corp.sgi.com (Postfix) with ESMTP id 521B9304032
	for <xfs@oss.sgi.com>; Sat, 13 Jun 2015 15:39:26 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net
	[150.101.137.145]) by cuda.sgi.com with ESMTP id
	bhh1gs6mFakPdHhA for <xfs@oss.sgi.com>;
	Sat, 13 Jun 2015 15:39:23 -0700 (PDT)
Date: Sun, 14 Jun 2015 08:39:21 +1000
From: Dave Chinner <david@fromorbit.com>
Subject: Re: your mail
Message-ID: <20150613223921.GC20262@dastard>
References: <71962FC942A61D42A3DECDFB7CC94F61193F6F07@STC-EXCH.stc.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <71962FC942A61D42A3DECDFB7CC94F61193F6F07@STC-EXCH.stc.local>
List-Id: XFS Filesystem from SGI <xfs.oss.sgi.com>
List-Unsubscribe: <http://oss.sgi.com/mailman/options/xfs>,
	<mailto:xfs-request@oss.sgi.com?subject=unsubscribe>
List-Archive: <http://oss.sgi.com/pipermail/xfs>
List-Post: <mailto:xfs@oss.sgi.com>
List-Help: <mailto:xfs-request@oss.sgi.com?subject=help>
List-Subscribe: <http://oss.sgi.com/mailman/listinfo/xfs>,
	<mailto:xfs-request@oss.sgi.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: xfs-bounces@oss.sgi.com
Sender: xfs-bounces@oss.sgi.com
To: Tom Christensen <tom.christensen@storagecraft.com>
Cc: "swakefie@redhat.com" <swakefie@redhat.com>, "xfs@oss.sgi.com" <xfs@oss.sgi.com>

On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> We've run into a bit of an issue with xfs running Ceph.  The following bug details what we are seeing:
> https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
> 
> Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
> 
> Here is additional info gathered:
> 
> xfs bmap output for a random directory
> https://gist.github.com/dmmatson/e864252c7ff346df954a
> 
> attr -l of the file dchinner indicated from the xfs bmap output
> (attr -l)
> (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> 
> xfs_bmap -vp of same file
> 
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000

And the attribute fork was:

rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
EXT: FILE-OFFSET	BLOCK-RANGE		AG AG-OFFSET          TOTAL FLAGS
  0: [0..7]:		1461176488..1461176495  8  (1163688..1163695)     8 00000
  1: [8..31]:		1461176504..1461176527  8  (1163704..1163727)    24 00000

I just created a filesystem and attribute list identical to the
above, and came up with a attribute fork that looks like:

/mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..7]:          120..127          0 (120..127)           8 00000
   1: [8..15]:         112..119          0 (112..119)           8 00000
   2: [16..23]:        104..111          0 (104..111)           8 00000

IOWs, there's an extra block in the attribute fork that is causing
problems than there needs to be.  That tends to imply attribute
overwrites might be contributing here (the 3-phase overwrite
algorithm increases the space usage) so I'm going to need to try a
few different things to see if I can get an attribute fork into the
same shape....

> LVM configuration: None
> 
> HGST 3TB
> 
> meta-data=/dev/mapper/63e3300b-6b7b-41a0-bdf2-b64ec3c20c51 isize=2048   agcount=32, agsize=22812700 blks

agcount=32 will actually be slowing your disks down. The default of
4AGs is usually best for a single spindle as it has sufficient
allocation cncurrency but results in much fewer seeks than a higher
AG count....

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xfs-bounces@oss.sgi.com>
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (Postfix) with ESMTP id 31B5E7F37
	for <xfs@oss.sgi.com>; Sun, 14 Jun 2015 18:27:47 -0500 (CDT)
Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11])
	by relay3.corp.sgi.com (Postfix) with ESMTP id C196CAC002
	for <xfs@oss.sgi.com>; Sun, 14 Jun 2015 16:27:43 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net
	[150.101.137.143]) by cuda.sgi.com with ESMTP id
	FniqbcMQiy2qPOF5 for <xfs@oss.sgi.com>;
	Sun, 14 Jun 2015 16:27:41 -0700 (PDT)
Date: Mon, 15 Jun 2015 09:27:38 +1000
From: Dave Chinner <david@fromorbit.com>
Subject: Re: your mail
Message-ID: <20150614232738.GD20262@dastard>
References: <71962FC942A61D42A3DECDFB7CC94F61193F6F07@STC-EXCH.stc.local>
	<20150613223921.GC20262@dastard>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20150613223921.GC20262@dastard>
List-Id: XFS Filesystem from SGI <xfs.oss.sgi.com>
List-Unsubscribe: <http://oss.sgi.com/mailman/options/xfs>,
	<mailto:xfs-request@oss.sgi.com?subject=unsubscribe>
List-Archive: <http://oss.sgi.com/pipermail/xfs>
List-Post: <mailto:xfs@oss.sgi.com>
List-Help: <mailto:xfs-request@oss.sgi.com?subject=help>
List-Subscribe: <http://oss.sgi.com/mailman/listinfo/xfs>,
	<mailto:xfs-request@oss.sgi.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: xfs-bounces@oss.sgi.com
Sender: xfs-bounces@oss.sgi.com
To: Tom Christensen <tom.christensen@storagecraft.com>
Cc: "swakefie@redhat.com" <swakefie@redhat.com>, "xfs@oss.sgi.com" <xfs@oss.sgi.com>

On Sun, Jun 14, 2015 at 08:39:21AM +1000, Dave Chinner wrote:
> On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> > We've run into a bit of an issue with xfs running Ceph.  The following bug details what we are seeing:
> > https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
> > 
> > Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
> > 
> > Here is additional info gathered:
> > 
> > xfs bmap output for a random directory
> > https://gist.github.com/dmmatson/e864252c7ff346df954a
> > 
> > attr -l of the file dchinner indicated from the xfs bmap output
> > (attr -l)
> > (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > 
> > xfs_bmap -vp of same file
> > 
> > rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> > (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> > (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000
> 
> And the attribute fork was:
> 
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> EXT: FILE-OFFSET	BLOCK-RANGE		AG AG-OFFSET          TOTAL FLAGS
>   0: [0..7]:		1461176488..1461176495  8  (1163688..1163695)     8 00000
>   1: [8..31]:		1461176504..1461176527  8  (1163704..1163727)    24 00000
> 
> I just created a filesystem and attribute list identical to the
> above, and came up with a attribute fork that looks like:
> 
> /mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
>    0: [0..7]:          120..127          0 (120..127)           8 00000
>    1: [8..15]:         112..119          0 (112..119)           8 00000
>    2: [16..23]:        104..111          0 (104..111)           8 00000
> 
> IOWs, there's an extra block in the attribute fork that is causing
> problems than there needs to be.  That tends to imply attribute
> overwrites might be contributing here (the 3-phase overwrite
> algorithm increases the space usage) so I'm going to need to try a
> few different things to see if I can get an attribute fork into the
> same shape....

I've had a test running overnight that generates attribute forks of
this shape, but I haven't seen any problems. sequential grow of
attributes, semi random growth, semi random truncation, etc don't
seem to trip over this problem on a 4.1-rc6 kernel. Hence I'm going
to need a metadump image of a filesystem with a broken file in it.
An obfuscated dump is fine; I only need to look at the structure of
the bad attribute fork. If you want to send the link privately to me
that is fine, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <linux-wireless-owner@vger.kernel.org>
Received: from out3.smtp.messagingengine.com ([66.111.4.27]:57337 "EHLO
	out3.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1754742AbYGAWxP (ORCPT
	<rfc822;linux-wireless@vger.kernel.org>);
	Tue, 1 Jul 2008 18:53:15 -0400
Date: Tue, 1 Jul 2008 19:53:10 -0300
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Michael Buesch <mb@bu3sch.de>,
	Adel Gadllah <adel.gadllah@gmail.com>,
	linux-wireless@vger.kernel.org, stefano.brivio@polimi.it,
	Larry Finger <larry.finger@lwfinger.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	Ivo van Doorn <ivdoorn@gmail.com>
Subject: Re: your mail
Message-ID: <20080701225310.GC4292@khazad-dum.debian.net> (sfid-20080702_005318_857170_D1B71841)
References: <20080701224817.GA4292@khazad-dum.debian.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20080701224817.GA4292@khazad-dum.debian.net>
Sender: linux-wireless-owner@vger.kernel.org
List-ID: <linux-wireless.vger.kernel.org>

On Tue, 01 Jul 2008, Henrique de Moraes Holschuh wrote:
> Bcc: 
> Subject: Re: [PATCH/RFC] b43: remove input device usage for rfkill
> Reply-To: 
> In-Reply-To: <1214937876.3462.10.camel@johannes.berg>
> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04  3738 EE25 DE3F
> 	1CDB 0FE3
> 
[...]

Sorry about this, hit the wrong key while adding Dmitry to the CC.  I have
resent it properly.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 15 Feb 1999 10:58:32 +0100 (MET)
From: Gabriel Paubert <paubert@iram.es>
To: Benjamin Herrenschmidt <bh40@calva.net>
cc: Paul Mackerras <paulus@cs.anu.edu.au>,
        Cort Dougan <cort@ladron.cs.nmt.edu>, linuxppc-dev@lists.linuxppc.org
Subject: Re: your mail
In-Reply-To: <19990213185009.020602@mail.mipsys.com>
Message-ID: <Pine.HPP.3.96.990215103957.5352f-100000@gra-ux1.iram.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linuxppc-dev@lists.linuxppc.org
List-Id: <linuxppc-dev@lists.linuxppc.org>




On Sat, 13 Feb 1999, Benjamin Herrenschmidt wrote:

> 
> Hi !
> 
> I would like your point of view about the following:
> 
> The kernel entry code starts playing with BATs as soon as it is entered.
> Isn't that dangerous ? I mean, you must have enough luck for this BAT not
> to be used at this specific time, or not overlapping another BAT setup by
> MacOS (overlapping BATs causes undefined behaviour according to the PPC
> manual) ?

One of the first steps I do in prepboot is to invalidate all the BATs and
all the TLB entries, to make sur that I start from a known state
(invalidating the BATs is a pain because it's different in 601 and
others). But then I'm quite sure I'm called with address translation
disabled, only that some FW version leave stale values in these registers. 

> I have made a test bootx that I'll upload to
> ftp.linuxppc.org/developement/users/benh later today (the archive will
> probably be called BootX_phys_test.sit). This version of BootX doesn't
> jump directly to the kernel but goes to a small piece of PPC asm that
> will cause the kernel to be entered with MMU (and interrupts) disabled. I
> beleive this should get rid of potential problems with TLB misses during
> boot too. Of course, all addresses passed to the kernel are turned into
> physical addresses (frame buffer, stack, boot_infos).

I still had problems with stale TLB entries between prepboot when the 
kernel enabled the MMU. You have to flush the TLB before starting the
kernel to be absolutely sure that there the kernel uses only translations 
it has defined (I discovered that I had added code accessing I/O 
space before the corresponding BATs were set up due to staale TLB
entries).

> This version works on my desktop G3, I didn't have time to test it on
> other machines yet.
> The bootstrap code is simple (it's entered with the same parameters as
> the kernel, but with physical addresses and with the kernel physical
> entry in r6) :
> 
>     /* switch interrupts off */
>     mfmsr   r0;
>     ori     r31,r31,MSR_EE;
>     andc    r0,r0,r31;
>     sync;
>     mtmsr   r0;
>     sync;

Wrong, what is in r31 before ? You may clear unwanted MSR bits:
	
	mfmsr	r0
	rlwinm  r0,r0,0,17,15
	mtmsr 	r0

is enough (And if you don't like using rlwinm like this, which is
guaranteed to work according to the architecture):
	
	mfmsr	r0
	ori	r0,r0,MSR_EE
	xori	r0,r0,MSR_EE
	mtmsr	r0

and you never need a sync before or after disabling interrupts. It is
different when enabling them however, because you have to make
sure that accesses to the interrupt controller have made it to the bus.  


> 
>     /* put kernel entry (phys) in ssr0 */
>     mtspr   SSR0, r6;
> 
>     /* Setup ssr1 (kernel entry MSR) */
>     ori     r31,r31,(MSR_IR|MSR_DR);
>     andc    r0,r0,r31;
>     mtspr   SSR1, r0;
> 
>     /* Branch to the kernel */
>     rfi;
> 
> Note: I wrote this little piece of asm with CodeWarrior. Since I would
> like to make a C boostrap that takes place between this and the kernel, I
> still need to figure out how to build code for this with egcs. If I could
> find the correct MakeFile options to get an output like prom.c
> (PC-relative branches, datas accessed thru a RELOC macro), I think it
> would be just fine. A better approach would be to store datas relative to
> a register that I can setup before entering the boostrap, but that means
> parsing enough of the ELF to extract the offset of the datas. I would
> appreciate if someone could give me some tips about what is usually done
> in those cases or some pointers to infos/samples.


I would recommend that you take a look at the patch files I have for
prep (only have a look at the prepboot directory): 

	ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz

it is even probably overkill for what you need. But the Makefile
(with -m rleocatable), the linker script (ppcboot.lds) and the
early boot (head.S) are probably good examples (and I tried to keep them
clean). 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

From mboxrd@z Thu Jan  1 00:00:00 1970
In-Reply-To: <Pine.HPP.3.96.990215103957.5352f-100000@gra-ux1.iram.es>
Date: Mon, 15 Feb 1999 12:23:01 +0100
To: Gabriel Paubert <paubert@iram.es>, linuxppc-dev@lists.linuxppc.org
From: Benjamin Herrenschmidt <bh40@calva.net>
Subject: Re: your mail
Message-Id: <19990215122301.003056@mail.mipsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linuxppc-dev@lists.linuxppc.org
List-Id: <linuxppc-dev@lists.linuxppc.org>


On Mon, Feb 15, 1999, Gabriel Paubert <paubert@iram.es> wrote:

>One of the first steps I do in prepboot is to invalidate all the BATs and
>all the TLB entries, to make sur that I start from a known state
>(invalidating the BATs is a pain because it's different in 601 and
>others). But then I'm quite sure I'm called with address translation
>disabled, only that some FW version leave stale values in these registers. 

My bootstrap is now a two-step bootstrap too, written all in asm to avoid
relocation problems. 

>I still had problems with stale TLB entries between prepboot when the 
>kernel enabled the MMU. You have to flush the TLB before starting the
>kernel to be absolutely sure that there the kernel uses only translations 
>it has defined (I discovered that I had added code accessing I/O 
>space before the corresponding BATs were set up due to staale TLB
>entries).

Since the MMU is switched off by the boostrap, I beleive those TLB
entries won't do any harm until the kernel switches the MMU back on,
that's it ? (I just want to make sure I fully understand). So, basically,
I could add to my bootstrap a piece of code that invalidates all BATs and
flush the TLB (I'll look at your preploader code for that).

>Wrong, what is in r31 before ? You may clear unwanted MSR bits:

You are right. I already changed this to rlwinm approx. 5 minutes after
sending the previous mail ;-)
	
>	mfmsr	r0
>	rlwinm  r0,r0,0,17,15
>	mtmsr 	r0
>
>is enough (And if you don't like using rlwinm like this, which is
>guaranteed to work according to the architecture):
>	
>	mfmsr	r0
>	ori	r0,r0,MSR_EE
>	xori	r0,r0,MSR_EE
>	mtmsr	r0
>
>and you never need a sync before or after disabling interrupts. It is
>different when enabling them however, because you have to make
>sure that accesses to the interrupt controller have made it to the bus.  

Ok, so I'll finally remove this sync.

>I would recommend that you take a look at the patch files I have for
>prep (only have a look at the prepboot directory): 
>
>	ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz
>
>it is even probably overkill for what you need. But the Makefile
>(with -m rleocatable), the linker script (ppcboot.lds) and the
>early boot (head.S) are probably good examples (and I tried to keep them
>clean). 

Ok, thanks.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 15 Feb 1999 15:18:01 +0100 (MET)
From: Gabriel Paubert <paubert@iram.es>
To: Benjamin Herrenschmidt <bh40@calva.net>
cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: your mail
In-Reply-To: <19990215122301.003056@mail.mipsys.com>
Message-ID: <Pine.HPP.3.96.990215145041.5352j-100000@gra-ux1.iram.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linuxppc-dev@lists.linuxppc.org
List-Id: <linuxppc-dev@lists.linuxppc.org>




On Mon, 15 Feb 1999, Benjamin Herrenschmidt wrote:

> My bootstrap is now a two-step bootstrap too, written all in asm to avoid
> relocation problems. 

Well, -m relocate is quite powerful IMHO. And I tried to write as little
assembly as possible, as you can easily guess from the 5000 lines of
PPC assembly of the x86 emulator :-)

> Since the MMU is switched off by the boostrap, I beleive those TLB
> entries won't do any harm until the kernel switches the MMU back on,
> that's it ? (I just want to make sure I fully understand). So, basically,
> I could add to my bootstrap a piece of code that invalidates all BATs and
> flush the TLB (I'll look at your preploader code for that).

No, but I need to run the bootloader mostly with MMU on to initialize the
VGA boards by emulating the VGA ROM BIOS for 2 reasons:
- having correct memeory attributes and the caches enabled,
- emulating the 1Mb of Intel Mobo (640k RAM+128k VGA+ ROM BIOS...)

I found that if I did not invalidate the TLB before starting the kernel, I
was allowed to do strange things (specifically accessing I/O space before
it was even mapped by BATs or PTE) due to stale TLB entries.  This caused
the introduction of a few bugs in some versions of my PreP initialization
code which were extremely hard to find. I even was unlucky enough to fall
on the borderline case where adding or suppressing a single debug message
in the loader cause the critical TLB entry to be valid or invalid.

Note that my code to invalidate TLB is the hammer to kill flies method: it
is guaranteed to work for all PPC (except embedded) implementations from
the architectural handbook because I don't want to rely on any system info
(too often wrong), so I invalidate 65536 TLB entries. In a bootloader, I
obviously don't care about the couple of milliseconds it takes. 

> 
> >Wrong, what is in r31 before ? You may clear unwanted MSR bits: 
> 
> You are right. I already changed this to rlwinm approx. 5 minutes after
> sending the previous mail ;-)

Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
to replace the last 2 parameters by a single value (bit mask), for
example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
complementary mask (ones, zeros, ones) so you can't type rlwinm
r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
rlwinm instruction. Anybody wants to tweak binutils to allow this ?

	Gabriel. 


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <9902151742.AA37298@marc.watson.ibm.com>
To: Gabriel Paubert <paubert@iram.es>
Cc: Benjamin Herrenschmidt <bh40@calva.net>, linuxppc-dev@lists.linuxppc.org
Subject: Re: your mail 
In-Reply-To: Message from Gabriel Paubert <paubert@iram.es>
   of "Mon, 15 Feb 1999 15:18:01 +0100." <Pine.HPP.3.96.990215145041.5352j-100000@gra-ux1.iram.es>
Date: Mon, 15 Feb 1999 12:42:55 -0500
From: David Edelsohn <dje@watson.ibm.com>
Sender: owner-linuxppc-dev@lists.linuxppc.org
List-Id: <linuxppc-dev@lists.linuxppc.org>


>>>>> Gabriel Paubert writes:

Gabriel> Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
Gabriel> to replace the last 2 parameters by a single value (bit mask), for
Gabriel> example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
Gabriel> complementary mask (ones, zeros, ones) so you can't type rlwinm
Gabriel> r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
Gabriel> rlwinm instruction. Anybody wants to tweak binutils to allow this ?

	I think that this already was discovered and fixed in the
development sources.  From the ChangeLog:

Wed Aug 12 14:00:38 1998  Ian Lance Taylor  <ian@cygnus.com>

        From Peter Thiemann <thiemann@informatik.uni-tuebingen.de>:
        * ppc-opc.c (insert_mbe): Handle wrapping bitmasks.
        (extract_mbe): Likewise.

David

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 14 Jul 2000 12:00:58 +0200 (METDST)
From: Gabriel Paubert <paubert@iram.es>
To: Crusman <Crusman@wanadoo.fr>
cc: ppc_mailing <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: your mail
In-Reply-To: <001e01bfed04$b27494a0$29e58aa4@crusman>
Message-ID: <Pine.HPX.4.10.10007141157010.9548-100000@gra-ux1.iram.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linuxppc-embedded@lists.linuxppc.org
List-Id: <linuxppc-embedded@lists.linuxppc.org>


On Thu, 13 Jul 2000, Crusman wrote:

> >The configurations I have are for 2600 with a PMC graphics board, remove
> >CONFIG_VT from the setup and it will use a serial console.
> >
> >BTW use PrePboot for these boards (CONFIG_PREPBOOT) since it gives a nicer
> >PCI layout to access the VMEbus...
> >
> >Please use the patches mvme2600.*.bz2...
>
> I have tested the patches but the new kernel don't see the scsi device...so
> I can't try it anyway !

Did you try the nfsroot (or nfsinstall but it's probably broken now) ? The
nfsroot does not have any CONFIG_VT set so it should work. At least it
works on headless 2600 and 2400.

> Yes, I have tested your kernel, but there is a message ( PC keyb error... or
> something like this) wich lock the kernel during the boot ! It's probably
> due to the Virtual Terminal support in the kernel !
> I always use the "console=ttyS0,9600" kernel option.

Then it should not do this, I don't know what happens. AFAIR it works on
MVME2400 whcih don't have the KB controller either.

> In short :
>
> - I can't use your kernel because of the PC_key error !
> - I can't patch & build a new kernel because this new kernel don't see my
> SCSI PMC !

Did you ever see the PMC module with some kernel ? Once booted (an nfsrrot
system is the best for this), see what you have in /proc/bus/pci.

	Gabriel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Leblond <eric@inl.fr>
Subject: Re: your mail
Date: Mon, 28 Jul 2008 16:14:09 +0200
Message-ID: <20080728141409.GC27519@khasse.inl.fr>
References: <009301c8ef85$a7389050$f5a9b0f0$@com>
Mime-Version: 1.0
Return-path: <netfilter-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <009301c8ef85$a7389050$f5a9b0f0$@com>
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Boulding <davidboulding@gmail.com>
Cc: netfilter@vger.kernel.org

Hello,

On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> Hey all,
> 
> I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> capture packets of interest on a bridge for analysis (firewall). 
> I use nfq_get_payload() to grab everything from the IP layer and on, but I
> was wondering if there was any way to get the raw MAC layer. 
> Is there any command like nfq_get_payload() that will return everything
> similar to what you would get using wireshark or ethereal?

You can use nfq_get_packet_hw():

	Retrieves the hardware address associated with the given queued packet.
	For ethernet packets, the hardware address returned (if any) will be the
	MAC address of the packet source host.  The destination MAC address is not
	known until after POSTROUTING and a successful ARP request, so cannot
	currently be retrieved.

	The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:

		struct nfqnl_msg_packet_hw {
			u_int16_t	hw_addrlen;
			u_int16_t	_pad;
			u_int8_t	hw_addr[8];
		} __attribute__ ((packed));
.

http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David Boulding" <davidboulding@gmail.com>
Subject: Re: your mail
Date: Mon, 28 Jul 2008 10:42:58 -0400
Message-ID: <5226fb870807280742l156c15fm909ae92c3cb2ad2f@mail.gmail.com>
References: <009301c8ef85$a7389050$f5a9b0f0$@com>
	 <20080728141409.GC27519@khasse.inl.fr>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <netfilter-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=0X3FOwQBznBAHQ35nxJzg3ldWPiftLGdMIbWCpqAmYQ=;
        b=XxNSsz13taucvo8Sb7jw0tqDbhpZEsFhHMBXkY4hsQvrqEvlrG9BLBb6gNHi97n/9j
         +FRcNyUmHBepUf1TpqGjiMdsnA6dQT1RfI+UrTHKrRv414KdbpPHIzD0vb6C05qwB7t0
         B4cWvLBg0wPV5SIYxoXNinZ/PL5N9f+mj7FHs=
In-Reply-To: <20080728141409.GC27519@khasse.inl.fr>
Content-Disposition: inline
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Eric Leblond <eric@inl.fr>, David Boulding <davidboulding@gmail.com>, netfilter@vger.kernel.org

Thanks for the reply.
I knew of nfq_get_packet_hw(), but I'm looking for a way to get the
raw byte array of the header that I get from the nfq_get_payload()
call. I'm not only looking for the MAC header information (which
nfq_get_packet_hw() will give me easy enough), but whatever else is
there, for example PPPoE and PPP header information. Is there anyway
to get that?

Thanks,

Dave

On Mon, Jul 28, 2008 at 10:14 AM, Eric Leblond <eric@inl.fr> wrote:
>
> Hello,
>
> On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> > Hey all,
> >
> > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> > capture packets of interest on a bridge for analysis (firewall).
> > I use nfq_get_payload() to grab everything from the IP layer and on, but I
> > was wondering if there was any way to get the raw MAC layer.
> > Is there any command like nfq_get_payload() that will return everything
> > similar to what you would get using wireshark or ethereal?
>
> You can use nfq_get_packet_hw():
>
>        Retrieves the hardware address associated with the given queued packet.
>        For ethernet packets, the hardware address returned (if any) will be the
>        MAC address of the packet source host.  The destination MAC address is not
>        known until after POSTROUTING and a successful ARP request, so cannot
>        currently be retrieved.
>
>        The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:
>
>                struct nfqnl_msg_packet_hw {
>                        u_int16_t       hw_addrlen;
>                        u_int16_t       _pad;
>                        u_int8_t        hw_addr[8];
>                } __attribute__ ((packed));
> .
>
> http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Leblond <eric@inl.fr>
Subject: Re: your mail
Date: Mon, 28 Jul 2008 16:43:41 +0200
Message-ID: <20080728144341.GD27519@khasse.inl.fr>
References: <009301c8ef85$a7389050$f5a9b0f0$@com> <20080728141409.GC27519@khasse.inl.fr> <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8"
Return-path: <netfilter-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
To: David Boulding <davidboulding@gmail.com>
Cc: netfilter@vger.kernel.org


--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
> Thanks for the reply.
> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw b=
yte
> > >
> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ."=
 to
> > > capture packets of interest on a bridge for analysis (firewall).

As you said "analysis", you may only want to "sniff" packet. In that case,
you can use NFLOG (latest git) or ULOG.

NFQUEUE moudle uses the dev_parse_header() function which only return the
source hardware address. You will not be able to retrieve the wanted
information without patching the kernel.

BR,
--=20
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiN2x0ACgkQnxA7CdMWjzJSmQCdHBt2ro5Tx7m5GbWhl7uGZz7l
5H8Anjc9CaBwO/tOVaywfm+WwzeeBayE
=felb
-----END PGP SIGNATURE-----

--JP+T4n/bALQSJXh8--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David Boulding" <davidboulding@gmail.com>
Subject: Re: your mail
Date: Mon, 28 Jul 2008 11:33:24 -0400
Message-ID: <5226fb870807280833x5eccb178jf8fc16740396b33b@mail.gmail.com>
References: <009301c8ef85$a7389050$f5a9b0f0$@com>
	 <20080728141409.GC27519@khasse.inl.fr>
	 <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
	 <20080728144341.GD27519@khasse.inl.fr>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <netfilter-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=yXcCvKq8IFJo+PCOcAvbqdChdfsDOSqHAAb4nU4rm90=;
        b=s+qWA641F3Ra6gtrATWXqMoPBWy2sY2siTlKJVG8JUi1tZQ02iXoEJFO2SpmbqOPuF
         SSqK+SUC18htnzqq6MCeToVIsc1qL/0Rvq7OWtb0C5PoUudY6pCUGNGPw3T/iH0lmslL
         XzRjWjYCjLOdb0tLD8KpoC9rvbaIOBiuE2F1c=
In-Reply-To: <20080728144341.GD27519@khasse.inl.fr>
Content-Disposition: inline
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Eric Leblond <eric@inl.fr>, David Boulding <davidboulding@gmail.com>, netfilter@vger.kernel.org

I've never heard of NFLOG or ULOG, is there any documentation under
netfilter on how to use it? How would I get the data that I want (to
sniff) using NFLOG/ULOG?

Dave

On Mon, Jul 28, 2008 at 10:43 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
>> Thanks for the reply.
>> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw byte
>> > >
>> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
>> > > capture packets of interest on a bridge for analysis (firewall).
>
> As you said "analysis", you may only want to "sniff" packet. In that case,
> you can use NFLOG (latest git) or ULOG.
>
> NFQUEUE moudle uses the dev_parse_header() function which only return the
> source hardware address. You will not be able to retrieve the wanted
> information without patching the kernel.
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkiN2x0ACgkQnxA7CdMWjzJSmQCdHBt2ro5Tx7m5GbWhl7uGZz7l
> 5H8Anjc9CaBwO/tOVaywfm+WwzeeBayE
> =felb
> -----END PGP SIGNATURE-----
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Leblond <eric@inl.fr>
Subject: Re: your mail
Date: Tue, 29 Jul 2008 09:11:30 +0200
Message-ID: <20080729071130.GA5383@bayen.regit.org>
References: <009301c8ef85$a7389050$f5a9b0f0$@com> <20080728141409.GC27519@khasse.inl.fr> <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com> <20080728144341.GD27519@khasse.inl.fr> <5226fb870807280833x5eccb178jf8fc16740396b33b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Return-path: <netfilter-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <5226fb870807280833x5eccb178jf8fc16740396b33b@mail.gmail.com>
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
To: David Boulding <davidboulding@gmail.com>
Cc: netfilter@vger.kernel.org


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
> I've never heard of NFLOG or ULOG, is there any documentation under
> netfilter on how to use it? How would I get the data that I want (to
> sniff) using NFLOG/ULOG?

For ULOG, you can have a look at ulogd or ulogd2 code.
	http://git.netfilter.org/cgi-bin/gitweb.cgi?p=3Dulogd2.git;a=3Dblob;f=3Din=
put/packet/ulogd_inppkt_ULOG.c;h=3Dc00d9bf8a965be7f961738892e19191efcf8f691=
;hb=3D0b789ea9bf810497845456e9b83bff8c5ae5ca23
By the way, as ulogd2 uses a plugin mechanism, you may be able to build
what you want by coding an ulogd2 plugin. It can provide you a way to
code something independant from low level (NFLOG or ULOG can be used as
input without changing your plugin).

A mini doc about ulogd2 hacking is available here:
	http://home.regit.org/?page_id=3D90

For NFLOG, you need to use latest git for kernel and libnetfilter_log.

The following functions are available:

- nflog_get_hwtype: to fetch hardware type (and thus give the parser to
  use)
- nflog_get_msg_packet_hwhdrlen: to get hardware header len
- nflog_get_msg_packet_hwhdr: get hardware datas

BR,
--=20
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIjsKinxA7CdMWjzIRAofmAJ9mi4P5SRkPugu8wADwtmB2LlHmigCfWjNn
E77TPzKV3LStdfYgpFCobVA=
=ruvK
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David Boulding" <davidboulding@gmail.com>
Subject: Re: your mail
Date: Tue, 29 Jul 2008 16:09:29 -0400
Message-ID: <5226fb870807291309q42b4c226q971aa487bd3703eb@mail.gmail.com>
References: <009301c8ef85$a7389050$f5a9b0f0$@com>
	 <20080728141409.GC27519@khasse.inl.fr>
	 <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
	 <20080728144341.GD27519@khasse.inl.fr>
	 <5226fb870807280833x5eccb178jf8fc16740396b33b@mail.gmail.com>
	 <20080729071130.GA5383@bayen.regit.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <netfilter-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=mlRbgKMOsu7mjxkiZ4iwMkfaaeoTKlgLfDH4l16XbZE=;
        b=XJjbyjLuWYVjJk9DUWosUXEBxxqUaQ4KUKcXEQtadT3GWq67hqF5mCTiH1M5ZTRjZd
         dWwX0CjfkO9ZqwgXyVnnSc0m1ivEch/qEQ5vdw20OYJGa36umIgxyc8+ptEdTXFwlPfI
         93Umk6Yj3oprfz18xNmmj4ALVhUFPxWsetBM0=
In-Reply-To: <20080729071130.GA5383@bayen.regit.org>
Content-Disposition: inline
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Eric Leblond <eric@inl.fr>, David Boulding <davidboulding@gmail.com>, netfilter@vger.kernel.org

Thanks for the help!

Dave

On Tue, Jul 29, 2008 at 3:11 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
>> I've never heard of NFLOG or ULOG, is there any documentation under
>> netfilter on how to use it? How would I get the data that I want (to
>> sniff) using NFLOG/ULOG?
>
> For ULOG, you can have a look at ulogd or ulogd2 code.
>        http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=input/packet/ulogd_inppkt_ULOG.c;h=c00d9bf8a965be7f961738892e19191efcf8f691;hb=0b789ea9bf810497845456e9b83bff8c5ae5ca23
> By the way, as ulogd2 uses a plugin mechanism, you may be able to build
> what you want by coding an ulogd2 plugin. It can provide you a way to
> code something independant from low level (NFLOG or ULOG can be used as
> input without changing your plugin).
>
> A mini doc about ulogd2 hacking is available here:
>        http://home.regit.org/?page_id=90
>
> For NFLOG, you need to use latest git for kernel and libnetfilter_log.
>
> The following functions are available:
>
> - nflog_get_hwtype: to fetch hardware type (and thus give the parser to
>  use)
> - nflog_get_msg_packet_hwhdrlen: to get hardware header len
> - nflog_get_msg_packet_hwhdr: get hardware datas
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIjsKinxA7CdMWjzIRAofmAJ9mi4P5SRkPugu8wADwtmB2LlHmigCfWjNn
> E77TPzKV3LStdfYgpFCobVA=
> =ruvK
> -----END PGP SIGNATURE-----
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "G.W. Haywood" <netfilter@jubileegroup.co.uk>
Subject: Re: your mail
Date: Sun, 28 Jun 2020 07:27:48 +0100 (BST)
Message-ID: <alpine.DEB.2.21.2006280724080.13515@piplus.local.jubileegroup.co.uk>
References: <CAK9MGy3D5UBf06OY16UW=c+Cybm67x+0kH_OWJkX7ywdQD9CNA@mail.gmail.com>
Mime-Version: 1.0
Return-path: <netfilter-owner@vger.kernel.org>
In-Reply-To: <CAK9MGy3D5UBf06OY16UW=c+Cybm67x+0kH_OWJkX7ywdQD9CNA@mail.gmail.com>
Sender: netfilter-owner@vger.kernel.org
List-ID: <netfilter.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
To: netfilter@vger.kernel.org

Hi there,

On Sat, 27 Jun 2020, helen wrote:

> ... lies snipped ...

If anyone is interested, I can stop this with a milter.

-- 

73,
Ged.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Harald Welte <laforge@gnumonks.org>
Subject: Re: your mail
Date: Wed, 3 Dec 2003 17:32:35 +0530
Sender: netfilter-devel-admin@lists.netfilter.org
Message-ID: <20031203120235.GG15715@obroa-skai.de.gnumonks.org>
References: <13724513568.20031119014829@internetplustravel.ru>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="zhtSGe8h3+lMyY1M"
Cc: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>,
	Martin Josefsson <gandalf@wlug.westbo.se>
Return-path: <netfilter-devel-admin@lists.netfilter.org>
To: Oleg Savostyanov <savostyanov@internetplustravel.ru>
Content-Disposition: inline
In-Reply-To: <13724513568.20031119014829@internetplustravel.ru>
Errors-To: netfilter-devel-admin@lists.netfilter.org
List-Help: <mailto:netfilter-devel-request@lists.netfilter.org?subject=help>
List-Post: <mailto:netfilter-devel@lists.netfilter.org>
List-Subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter-devel>,
	<mailto:netfilter-devel-request@lists.netfilter.org?subject=subscribe>
List-Unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter-devel>,
	<mailto:netfilter-devel-request@lists.netfilter.org?subject=unsubscribe>
List-Archive: <https://lists.netfilter.org/pipermail/netfilter-devel/>
List-Id: netfilter-devel.vger.kernel.org


--zhtSGe8h3+lMyY1M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 19, 2003 at 01:48:07AM +0300, Oleg Savostyanov wrote:
> Hello , Harald
> I tryed to install extra package, written by you -
> pptp-conntrack-nat
> but failed to do this.

please report such problems to netfilter@lists.gnumonks.org, or
netfilter-devel@lists.gnumonks.org (like documented on
http://www.netfilter.org/contact.html).

also, which version of patch-o-matic were you using?

> Do you have any ideas what to do?

Martin Josefsson is the patch-o-matic maintainer, maybe he can help you.

--=20
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Programming is like sex: One mistake and you have to support it your lifeti=
me

--zhtSGe8h3+lMyY1M
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/zdDwXaXGVTD0i/8RAs9HAJ97Gjv/WIIXS5pfnxYk1GJmJmRmVwCdF2/7
kgmKOTeZmyezUVkseGdQMA0=
=yRQc
-----END PGP SIGNATURE-----

--zhtSGe8h3+lMyY1M--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Harald Welte <laforge@netfilter.org>
Subject: Re: your mail
Date: Tue, 30 Aug 2005 16:09:23 +0200
Message-ID: <20050830140923.GD4221@rama.de.gnumonks.org>
References: <200508301321.j7UDLV9k002943@toshiba.co.jp>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv"
Cc: netfilter-devel@lists.netfilter.org, pablo@netfilter.org
Return-path: <netfilter-devel-bounces@lists.netfilter.org>
To: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Content-Disposition: inline
In-Reply-To: <200508301321.j7UDLV9k002943@toshiba.co.jp>
List-Unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter-devel>,
	<mailto:netfilter-devel-request@lists.netfilter.org?subject=unsubscribe>
List-Archive: </pipermail/netfilter-devel>
List-Post: <mailto:netfilter-devel@lists.netfilter.org>
List-Help: <mailto:netfilter-devel-request@lists.netfilter.org?subject=help>
List-Subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter-devel>,
	<mailto:netfilter-devel-request@lists.netfilter.org?subject=subscribe>
Sender: netfilter-devel-bounces@lists.netfilter.org
Errors-To: netfilter-devel-bounces@lists.netfilter.org
List-Id: netfilter-devel.vger.kernel.org


--8w3uRX/HFJGApMzv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 30, 2005 at 10:21:31PM +0900, Yasuyuki KOZAKAI wrote:
>=20
> Hi,
>=20
> If CONFIG_NF_IP_CONNTRACK=3Dy, CONFIG_NETFILTER_NETLINK=3Dm, and
> CONFIG_NF_CONNTRACK_NETLINK=3Dm, it's failed to build kernel
> of netfilter-2.6.14 git tree. Because __nfa_fill() in nfnetlink
> called from ip_conntrack isn't built into kernel image in this case.
> It's necessary to fix Kconfig or change source code to make dependencies
> more simple.

Thanks for pointing this out.

This problem will be fixed by Thomas Graf's generic netlink macros
(which will be part of the core network stack) which will be merged
during the net-2.6.14 process, so I think we can ignore
this for now.

--=20
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

--8w3uRX/HFJGApMzv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDFGiTXaXGVTD0i/8RAhUHAJ9rjlKvE3bd6xRcLi1oGZXOEaELnACghhOd
R4ljTNyLB3XV487ezKJi/kM=
=IN6t
-----END PGP SIGNATURE-----

--8w3uRX/HFJGApMzv--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 13:56:35 +0200 (CEST)
Message-ID: <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jan Engelhardt <jengelh@medozas.de>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from smtp-in.kfki.hu ([148.6.0.26]:51535 "EHLO smtp1.kfki.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755161Ab1HaL4h (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 07:56:37 -0400
In-Reply-To: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

Hi Jan,

On Sun, 28 Aug 2011, Jan Engelhardt wrote:

> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)

After rewieving your patches, I don't get it: what userspace tool would 
use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
definitely not use it and ipset either. So why your patches are 
required?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Engelhardt <jengelh@medozas.de>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 14:10:01 +0200 (CEST)
Message-ID: <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from seven.medozas.de ([188.40.89.202]:60271 "EHLO seven.medozas.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753842Ab1HaMKE (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 08:10:04 -0400
In-Reply-To: <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:

>Hi Jan,
>
>On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>
>> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>
>After rewieving your patches, I don't get it: what userspace tool would 
>use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>definitely not use it and ipset either. So why your patches are 
>required?

iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
#includes ip_set.h to get at the definition of ip_set.h.
Patch will be resent.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 14:16:44 +0200 (CEST)
Message-ID: <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jan Engelhardt <jengelh@medozas.de>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from smtp-in.kfki.hu ([148.6.0.28]:37556 "EHLO smtp2.kfki.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755161Ab1HaMQp (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 08:16:45 -0400
In-Reply-To: <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> 
> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >
> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >
> >After rewieving your patches, I don't get it: what userspace tool would 
> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >definitely not use it and ipset either. So why your patches are 
> >required?
> 
> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> #includes ip_set.h to get at the definition of ip_set.h.
> Patch will be resent.

iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
xt_set.h includes nothing.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Engelhardt <jengelh@medozas.de>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 14:44:59 +0200 (CEST)
Message-ID: <alpine.LNX.2.01.1108311444300.30915@frira.zrqbmnf.qr>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from seven.medozas.de ([188.40.89.202]:53365 "EHLO seven.medozas.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755169Ab1HaMpA (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 08:45:00 -0400
In-Reply-To: <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:

>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>> 
>> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >
>> >After rewieving your patches, I don't get it: what userspace tool would 
>> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>> >definitely not use it and ipset either. So why your patches are 
>> >required?
>> 
>> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
>> #includes ip_set.h to get at the definition of ip_set.h.
>> Patch will be resent.
>
>iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
>xt_set.h includes nothing.

14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
#include <linux/types.h>
#include <linux/netfilter/ipset/ip_set.h>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 14:49:39 +0200 (CEST)
Message-ID: <alpine.DEB.2.00.1108311447070.31028@blackhole.kfki.hu>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
 <alpine.LNX.2.01.1108311444300.30915@frira.zrqbmnf.qr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jan Engelhardt <jengelh@medozas.de>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from smtp2.kfki.hu ([148.6.0.28]:54297 "EHLO smtp2.kfki.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755169Ab1HaMtl (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 08:49:41 -0400
In-Reply-To: <alpine.LNX.2.01.1108311444300.30915@frira.zrqbmnf.qr>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
> 
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >> 
> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >
> >> >After rewieving your patches, I don't get it: what userspace tool would 
> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >> >definitely not use it and ipset either. So why your patches are 
> >> >required?
> >> 
> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> Patch will be resent.
> >
> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
> >xt_set.h includes nothing.
> 
> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> #include <linux/types.h>
> #include <linux/netfilter/ipset/ip_set.h>

This is the kernel source tree. You wrote about libxt_SET.c and userspace:

kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
kadlec@mentat:/usr/src/git/iptables$ 

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Engelhardt <jengelh@medozas.de>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 15:04:36 +0200 (CEST)
Message-ID: <alpine.LNX.2.01.1108311502150.7962@frira.zrqbmnf.qr>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
 <alpine.LNX.2.01.1108311444300.30915@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311447070.31028@blackhole.kfki.hu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from seven.medozas.de ([188.40.89.202]:47584 "EHLO seven.medozas.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755656Ab1HaNEi (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 09:04:38 -0400
In-Reply-To: <alpine.DEB.2.00.1108311447070.31028@blackhole.kfki.hu>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:

>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
>> 
>> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>> >> 
>> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >> >
>> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >> >
>> >> >After rewieving your patches, I don't get it: what userspace tool would 
>> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>> >> >definitely not use it and ipset either. So why your patches are 
>> >> >required?
>> >> 
>> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
>> >> #includes ip_set.h to get at the definition of ip_set.h.
>> >> Patch will be resent.
>> >
>> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
>> >xt_set.h includes nothing.
>> 
>> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
>> #include <linux/types.h>
>> #include <linux/netfilter/ipset/ip_set.h>
>
>This is the kernel source tree. You wrote about libxt_SET.c and userspace:
>
>kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
>kadlec@mentat:/usr/src/git/iptables$ 

Of course the header files in the iptables source tree come from the 
(sanitized) kernel headers, and time and again, new copies from the 
kernel are brought into the iptables tree.

(Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5, 
350661a6eb089f3e54e67e022db9e16ea280499f, 
978e27e8f8c2e49d0528c6c4ae3a56627fbe8492, 
e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the 
past.)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: your mail
Date: Wed, 31 Aug 2011 15:24:38 +0200 (CEST)
Message-ID: <alpine.DEB.2.00.1108311520040.31028@blackhole.kfki.hu>
References: <alpine.LNX.2.01.1108281611060.31802@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311352450.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311409060.2589@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311414470.31028@blackhole.kfki.hu>
 <alpine.LNX.2.01.1108311444300.30915@frira.zrqbmnf.qr> <alpine.DEB.2.00.1108311447070.31028@blackhole.kfki.hu> <alpine.LNX.2.01.1108311502150.7962@frira.zrqbmnf.qr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
To: Jan Engelhardt <jengelh@medozas.de>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from smtp1.kfki.hu ([148.6.0.26]:43722 "EHLO smtp1.kfki.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755757Ab1HaNYj (ORCPT <rfc822;netfilter-devel@vger.kernel.org>);
	Wed, 31 Aug 2011 09:24:39 -0400
In-Reply-To: <alpine.LNX.2.01.1108311502150.7962@frira.zrqbmnf.qr>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:
> 
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
> >> 
> >> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >> >> 
> >> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >> >
> >> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >> >
> >> >> >After rewieving your patches, I don't get it: what userspace tool would 
> >> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >> >> >definitely not use it and ipset either. So why your patches are 
> >> >> >required?
> >> >> 
> >> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> >> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> >> Patch will be resent.
> >> >
> >> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
> >> >xt_set.h includes nothing.
> >> 
> >> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> >> #include <linux/types.h>
> >> #include <linux/netfilter/ipset/ip_set.h>
> >
> >This is the kernel source tree. You wrote about libxt_SET.c and userspace:
> >
> >kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
> >kadlec@mentat:/usr/src/git/iptables$ 
> 
> Of course the header files in the iptables source tree come from the 
> (sanitized) kernel headers, and time and again, new copies from the 
> kernel are brought into the iptables tree.
> 
> (Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5, 
> 350661a6eb089f3e54e67e022db9e16ea280499f, 
> 978e27e8f8c2e49d0528c6c4ae3a56627fbe8492, 
> e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the 
> past.)

Then I'm going to apply your patches. After that some more work is 
required from me, because ipset userspace assumes those parts to be 
excluded by #ifdef __KERNEL__.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from verein.lst.de (verein.lst.de [213.95.11.211])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC20372
	for <ntfs3@lists.linux.dev>; Mon, 16 Aug 2021 12:27:24 +0000 (UTC)
Received: by verein.lst.de (Postfix, from userid 2407)
	id C3DE96736F; Mon, 16 Aug 2021 14:27:21 +0200 (CEST)
Date: Mon, 16 Aug 2021 14:27:21 +0200
From: Christoph Hellwig <hch@lst.de>
To: Kari Argillander <kari.argillander@gmail.com>
Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
	Christoph Hellwig <hch@lst.de>, ntfs3@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Pali =?iso-8859-1?Q?Roh=E1r?= <pali@kernel.org>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: your mail
Message-ID: <20210816122721.GA17355@lst.de>
References: <20210816024703.107251-1-kari.argillander@gmail.com>
Precedence: bulk
X-Mailing-List: ntfs3@lists.linux.dev
List-Id: <ntfs3.lists.linux.dev>
List-Subscribe: <mailto:ntfs3+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:ntfs3+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210816024703.107251-1-kari.argillander@gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Mon, Aug 16, 2021 at 05:46:59AM +0300, Kari Argillander wrote:
> I would like really like to get fsparam_flag_no also for no_acs_rules
> but then we have to make new name for it. Other possibility is to
> modify mount api so it mount option can be no/no_. I think that would
> maybe be good change. 

I don't think adding another no_ alias is a good idea.  I'd suggest
to just rename the existing flag before the ntfs3 driver ever hits
mainline.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linas@austin.ibm.com>
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "e34.co.us.ibm.com", Issuer "Equifax" (verified OK))
	by ozlabs.org (Postfix) with ESMTP id 27004DDEDB
	for <linuxppc-dev@ozlabs.org>; Thu, 17 May 2007 02:43:55 +1000 (EST)
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com
	[9.17.195.106])
	by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l4GGhppF013927
	for <linuxppc-dev@ozlabs.org>; Wed, 16 May 2007 12:43:51 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
	l4GGhoSs199016
	for <linuxppc-dev@ozlabs.org>; Wed, 16 May 2007 10:43:50 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
	by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l4GGhoCd029468
	for <linuxppc-dev@ozlabs.org>; Wed, 16 May 2007 10:43:50 -0600
Date: Wed, 16 May 2007 11:43:41 -0500
To: Bob Picco <bob.picco@hp.com>, johnrose@us.ibm.com
Subject: Re: your mail
Message-ID: <20070516164341.GA7008@austin.ibm.com>
References: <20070516133046.GB25792@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20070516133046.GB25792@localhost>
From: linas@austin.ibm.com (Linas Vepstas)
Cc: linuxppc-dev@ozlabs.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.ozlabs.org>
List-Unsubscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=unsubscribe>
List-Archive: <http://ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@ozlabs.org?subject=help>
List-Subscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=subscribe>

On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> 
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> make[3]: *** [drivers/pci/hotplug] Error 2
> make[2]: *** [drivers/pci] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2

John Rose is working to fix this "real soon now".

--linas

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olof@lixom.net>
Received: from mail.lixom.net (lixom.net [66.141.50.11])
	by ozlabs.org (Postfix) with ESMTP id ACC6ADDEE6
	for <linuxppc-dev@ozlabs.org>; Thu, 17 May 2007 03:07:43 +1000 (EST)
Date: Wed, 16 May 2007 12:11:00 -0500
To: Linas Vepstas <linas@austin.ibm.com>
Subject: Re: your mail
Message-ID: <20070516171100.GA25056@lixom.net>
References: <20070516133046.GB25792@localhost>
	<20070516164341.GA7008@austin.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20070516164341.GA7008@austin.ibm.com>
From: olof@lixom.net (Olof Johansson)
Cc: linuxppc-dev@ozlabs.org, Andrew Morton <akpm@linux-foundation.org>,
	johnrose@us.ibm.com, linux-kernel@vger.kernel.org,
	Bob Picco <bob.picco@hp.com>
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.ozlabs.org>
List-Unsubscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=unsubscribe>
List-Archive: <http://ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@ozlabs.org?subject=help>
List-Subscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=subscribe>

On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > 
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
> 
> John Rose is working to fix this "real soon now".

Do you mean the fix Al Viro posted yesterday?

http://patchwork.ozlabs.org/linuxppc/patch?id=11177


-Olof

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bob.picco@hp.com>
Received: from ccerelrim01.cce.hp.com (smtp.cce.hp.com [161.114.21.22])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "ccerelrim01.cce.hp.com", Issuer "RSA Data Security,
	Inc." (verified OK)) by ozlabs.org (Postfix) with ESMTP id B5C30DDED2
	for <linuxppc-dev@ozlabs.org>; Thu, 17 May 2007 03:24:28 +1000 (EST)
From: "Bob Picco" <bob.picco@hp.com>
Date: Wed, 16 May 2007 13:24:21 -0400
To: Olof Johansson <olof@lixom.net>
Subject: Re: your mail
Message-ID: <20070516172421.GC25792@localhost>
References: <20070516133046.GB25792@localhost>
	<20070516164341.GA7008@austin.ibm.com>
	<20070516171100.GA25056@lixom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20070516171100.GA25056@lixom.net>
Cc: linux-kernel@vger.kernel.org, Bob Picco <bob.picco@hp.com>,
	linuxppc-dev@ozlabs.org,
	Andrew Morton <akpm@linux-foundation.org>, johnrose@us.ibm.com
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.ozlabs.org>
List-Unsubscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=unsubscribe>
List-Archive: <http://ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@ozlabs.org?subject=help>
List-Subscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=subscribe>

Olof Johansson wrote:	[Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > > 
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> > 
> > John Rose is working to fix this "real soon now".
> 
> Do you mean the fix Al Viro posted yesterday?
> 
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
> 
> 
> -Olof
Missed that patch.

thanks,

bob

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tony@bakeyournoodle.com>
Received: from thor.bakeyournoodle.com (ibmaus65.lnk.telstra.net
 [165.228.126.9])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (Client did not present a certificate)
 by ozlabs.org (Postfix) with ESMTPSA id B4263B708F
 for <linuxppc-dev@lists.ozlabs.org>; Wed, 23 Nov 2011 10:47:16 +1100 (EST)
Date: Wed, 23 Nov 2011 10:47:15 +1100
From: Tony Breeds <tony@bakeyournoodle.com>
To: LinuxPPC-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: your mail
Message-ID: <20111122234715.GB25264@thor.bakeyournoodle.com>
References: <20111122234245.GA28234@thor.bakeyournoodle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6"
In-Reply-To: <20111122234245.GA28234@thor.bakeyournoodle.com>
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.lists.ozlabs.org>
List-Unsubscribe: <https://lists.ozlabs.org/options/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>
List-Archive: <http://lists.ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@lists.ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>
List-Subscribe: <https://lists.ozlabs.org/listinfo/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>


--ZoaI/ZTpAVc4A5k6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Wed, Nov 23, 2011 at 10:42:45AM +1100, Tony Breeds wrote:
> From 1a44c074e3ce572cbf60d31ac704e6ce42be4708 Mon Sep 17 00:00:00 2001
> From: Tony Breeds <tony@bakeyournoodle.com>
> Date: Wed, 23 Nov 2011 10:16:40 +1100
> Subject: [PATCH] powerpc: 44x: Add mtd ndfc to the ppx44x defconfig

Sorry all for the SPAM.  I screwed up trying to use mutt and git to
send-email

Yours Tony

--ZoaI/ZTpAVc4A5k6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOzDSCAAoJEEsCiJRY75GK+KwQAI9dCQD8HP5blEA5ggALPwlX
VaEGAAsjrSbEd+1mRI5K7pa0KKhvwco8RJWqMbtflHrPqejJ34BQCICdopxwI2wb
uS6gcY/mBoE2Ga32fJKHgulZqvolsxuYffu/KhSZQrNeQxv0j1DzwPNXEqt2C3M1
pdDUKjxQ3sIv4jcz6FAlejGmV0iIUOYgDYOKpYbhzIosDHaUx0ygPXr/sbGJHBOJ
6zirOj0luPp/wshZrnaZdVJcPLRXiMEm5jNyi+Rpz4Eel92iP7UTatLpyFtl1FO8
sraSXDxc1s6/mHBjXYagY3HMQx62a6qw+d+6H0BqFgQ57HsD7aL5986GtawaQAr8
kHXvwbNVVOqiaayBL1mxRfvMkymwCh1aWAGmYwmO0Cka2AQ2U9xu/Qcqxl+LqS5s
9njKfK6vJbRQH8oZr8YHPTifTsN8Ml8hn+mCoDS1SQRXhUKK87vX8jnOvo3Z5sW0
QyHfep0EHMh3A4ycgIJGwVVtGnProNo7ndeGGZOvbAs/HfLy0NnERZpLrcMZW3r2
hXFCAO+BxBvgFbkSreZGsayuF6TdIzOxs/v1Sax9a8zyiwPzap4rAVad/5cN/9ZM
PoKFHLYGmQ5RWa1+A735z6WndhOGTQRoGl/UjXsh0xInScHFY3o0GrljBgGcJSXv
Bd+5he5+MhI6bY1MObc4
=0VF9
-----END PGP SIGNATURE-----

--ZoaI/ZTpAVc4A5k6--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DB387475
	for <outreachy@lists.linux.dev>; Fri, 17 Mar 2023 16:47:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=17/9NDWz9gFDC8Z6MlRaJGQBKJCZIA3U4GyZX98rAdA=;
  b=gc73WeyG7EfRqJjim4NL+R2bXtMsKvITH9ugW+kKWdUHjDC4kCzhwOCZ
   +9JqdQE90qAs8jtKP+aOzwPg/zQmVRrkgu87PZE/Cdf4tsTnQl2AbeQF1
   FDkfO6DtvHFAOyg7HrmmDzxBPSQLULcfV+y2mnDadIYJiUbxeR5IO9Wd/
   c=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.98,268,1673910000"; 
   d="scan'208";a="97816689"
Received: from dt-lawall.paris.inria.fr ([128.93.67.65])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2023 17:47:23 +0100
Date: Fri, 17 Mar 2023 17:47:23 +0100 (CET)
From: Julia Lawall <julia.lawall@inria.fr>
To: Sumitra Sharma <sumitraartsy@gmail.com>
cc: Bagas Sanjaya <bagasdotme@gmail.com>, 
    Linux Outreachy <outreachy@lists.linux.dev>
Subject: Re: your mail
In-Reply-To: <20230317163629.GB2392@sumitra.com>
Message-ID: <2123df9c-870-3a20-94b-7833bc66ad9@inria.fr>
References: <20230317163629.GB2392@sumitra.com>
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII



On Fri, 17 Mar 2023, Sumitra Sharma wrote:

> , fmdefrancesco@gmail.com
> Bcc:
> Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> Reply-To:
> In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
>
> On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > On 3/14/23 19:33, Sumitra Sharma wrote:
> > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > >> install your tools (including postfix and mutt) there if you want to
> > >> contribute through there. So I think the latter doc should be kept as
> > >> is.
> > >>
> > >
> > > Hi
> > >
> > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > it.
> > >
> >
> > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> >
> > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > for now. (But I wish the slug could be better named as LinuxVMSetup).
> >
>
> Hi,
>
> Since we discussed all about the outreachyfirstpatchalt only and you
> also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.

In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
called Set up email.  This is followed by some sections related to gmail,
yahoo, etc.  So you could find the best place around there for the new
information.

It could be nice to use some subsections, so that one can easily identify
the complete section about email.

I notice also that there seems to be randomly "set up" and "setup".  I
have the impression that "set up" is a verb and "setup" is a noun., so it
should be "Set up vim as your default editor" (not Setup...) and it should
be "Gmail setup" (not Gmail set up).

thanks,
julia

>
> 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
>
> 	- Open the ~/.muttrc
> 	- Add the information
>
> 		set sendmail="/usr/bin/esmtp"
> 		set envelope_from=yes
> 		set from="Your Name <my.email@gmail.com>"
> 		set use_from=yes
> 		set edit_headers=yes
>
> 		# IMAP settings
> 		set imap_user = "username@gmail.com"
> 		set imap_pass = "<mailbox password>"
>
> 		# SMTP settings
> 		set smtp_url = "smtps://username@smtp.gmail.com"
> 		set smtp_pass = "<mailbox password>"
>
> 		# Remote Gmail folders
> 		set folder = "imaps://imap.gmail.com/"
> 		set spoolfile = "+INBOX"
> 		set postponed = "+[Gmail]/Drafts"
> 		set record = "+[Gmail]/Sent Mail"
> 		set trash = "+[Gmail]/Trash"
>
> 	- Where the imap_pass, smtp_pass would be the App password or
> 	  the mailbox password.
>
>
> Regards,
>
> Sumitra
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B8B97494
	for <outreachy@lists.linux.dev>; Fri, 17 Mar 2023 18:17:50 +0000 (UTC)
Received: by mail-pj1-f50.google.com with SMTP id l9-20020a17090a3f0900b0023d32684e7fso8617872pjc.1
        for <outreachy@lists.linux.dev>; Fri, 17 Mar 2023 11:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112; t=1679077070;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=2+MBfAcf3sIGVCHr309Z4akavAO7Re7EcqWL1r4xsSg=;
        b=Btx8nd6LPwTQ4Jh+kvQwouwJ901xpE/U5aDgvHtqmn34RapSSmgjW1sNlRXLXujDXs
         ey4z8amlrJyqmvpiYfvkkJYSqGvvKOHr/9FxRWjyKYxoo8yJlTR1/eO+nulD34EWUoBW
         wtdLqh5ls6bKc1idETr/LORG95GENe8gQURwNrF6BrAUnOkTxUMk6fsjkAeT0SwGZIah
         gieaZUVOpuwwNwGx1jFC0Fm55/s5BmSO78yoDQjgztKaRGmf7kDu3g6VSy86IWe8iyc5
         j30rhnVuUwrrJ1AbKEIO8csnScWbhIgKeC2cqYZquMaCfEAcZCJoul/A0WiSYAzJ//hS
         Druw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1679077070;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2+MBfAcf3sIGVCHr309Z4akavAO7Re7EcqWL1r4xsSg=;
        b=5de+deQvRs4/fpOnwuETK8lX/n66RyvNhuMMLERF+RYu8z5eOF8enpgnkL8MUYYQK9
         DyklkpCjuv23wD9TJkrXgqaL9CLc+KtH4tUk+eJGNK+U1ICmDFOik6NGnMgoqUIzvDx6
         u0Wk6K/xvZ1mVQuFM+MKipIujc5hVBTROiQ7NEr4VMrZMe5OUkK2TJkC/rfLDEgO4i6U
         u86MDabo3F2mrwd2v97iLz9OrRHQXXR1330yhxA2YrfaZ8K+CzNlOwD0vgf2Be6Wqqch
         w+rBW+f1YHck9Rs9gruitMq/Dxvu9WSPIR8eTqwox2Z3zS74527QmHhTtYhZjuvHJNWY
         re+A==
X-Gm-Message-State: AO0yUKV7zHSThh/2jO1m5RaDhrgmFH4RbzjZw/XCH/RgvtLUVaAI94tb
	E6+EcPUrr1FPmDrEAEa42G0=
X-Google-Smtp-Source: AK7set+uWkV+j0dHggyZZ+4Wv0zzbWKmLrlhrKvingeVh21lrfdLfWwPRFOqwtP6vg/muULCl8gj9Q==
X-Received: by 2002:a05:6a20:8361:b0:c7:7afa:5016 with SMTP id z33-20020a056a20836100b000c77afa5016mr7038282pzc.9.1679077069704;
        Fri, 17 Mar 2023 11:17:49 -0700 (PDT)
Received: from sumitra.com ([117.98.68.136])
        by smtp.gmail.com with ESMTPSA id j8-20020aa78dc8000000b00571f66721aesm1872372pfr.42.2023.03.17.11.17.47
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 17 Mar 2023 11:17:49 -0700 (PDT)
Date: Fri, 17 Mar 2023 11:17:45 -0700
From: Sumitra Sharma <sumitraartsy@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
	Linux Outreachy <outreachy@lists.linux.dev>
Subject: Re: your mail
Message-ID: <20230317181745.GA3500@sumitra.com>
References: <20230317163629.GB2392@sumitra.com>
 <2123df9c-870-3a20-94b-7833bc66ad9@inria.fr>
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2123df9c-870-3a20-94b-7833bc66ad9@inria.fr>

On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
> 
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
> 
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email.  This is followed by some sections related to gmail,
> yahoo, etc.  So you could find the best place around there for the new
> information.
> 
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
> 

Actually, the only issue I faced was that the outreachyfirstpatch
document do not contain the informatio of how to set your inbox in mutt.
Due to which I was facing issues to send and reply mails. This below
configuration update will enable the inbox at the client side.

How about this...

Under the section "Configure esmtp":

###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:

Note: The imap_pass, smtp_pass would be the App password or
 	  the mailbox password.

 		set sendmail="/usr/bin/esmtp"
 		set envelope_from=yes
 		set from="Your Name <my.email@gmail.com>"
 		set use_from=yes
 		set edit_headers=yes

 		# IMAP settings
 		set imap_user = "username@gmail.com"
 		set imap_pass = "<mailbox password>"

 		# SMTP settings
 		set smtp_url = "smtps://username@smtp.gmail.com"
 		set smtp_pass = "<mailbox password>"

 		# Remote Gmail folders
 		set folder = "imaps://imap.gmail.com/"
 		set spoolfile = "+INBOX"
 		set postponed = "+[Gmail]/Drafts"
 		set record = "+[Gmail]/Sent Mail"
 		set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup".  I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>

Okay! I will take care of it. Thank you.

Regards,

Sumitra

> thanks,
> julia
> 
> >
> > 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
> >
> > 	- Open the ~/.muttrc
> > 	- Add the information
> >
> > 		set sendmail="/usr/bin/esmtp"
> > 		set envelope_from=yes
> > 		set from="Your Name <my.email@gmail.com>"
> > 		set use_from=yes
> > 		set edit_headers=yes
> >
> > 		# IMAP settings
> > 		set imap_user = "username@gmail.com"
> > 		set imap_pass = "<mailbox password>"
> >
> > 		# SMTP settings
> > 		set smtp_url = "smtps://username@smtp.gmail.com"
> > 		set smtp_pass = "<mailbox password>"
> >
> > 		# Remote Gmail folders
> > 		set folder = "imaps://imap.gmail.com/"
> > 		set spoolfile = "+INBOX"
> > 		set postponed = "+[Gmail]/Drafts"
> > 		set record = "+[Gmail]/Sent Mail"
> > 		set trash = "+[Gmail]/Trash"
> >
> > 	- Where the imap_pass, smtp_pass would be the App password or
> > 	  the mailbox password.
> >
> >
> > Regards,
> >
> > Sumitra
> >
> >

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06BEEEC6
	for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 08:10:03 +0000 (UTC)
Received: by mail-pl1-f176.google.com with SMTP id i5so9530388pla.2
        for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 01:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112; t=1679213403;
        h=in-reply-to:content-disposition:mime-version:message-id:subject:to
         :from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=0AIg6djfD3Z8OLbEjaJ/Dktvn8yVMGHT+GXUl6YhXpc=;
        b=EwHsQk6Wny+JUiJmEsemEPvZ7AuQvuOk8vZo2hCiwQPR/tJfpDUTK2p9ZHm/wznYXP
         Gc6MUa2fG6cNWnbKtfaQ4urCdBZy3y55C/5+bLHLYtb40EnELwnh6j8dlFuzYxNq+ijw
         Qn8QKYBUtMhFDXu6fZ5VpjqWpAvRbwlytLollrztLJYeDCzoXEdj7CKS/kc5gInA1vKY
         0pKjAuuTbLhEyObqrQAtXQDVdbZvCe9vOA7dscf3RXQSqBU+21rbNXRiLzZ57KLl4GFx
         qPP/CJmdiyqf18Xz+W6yUAar/UO+QIB/LmS/AGLzMBfs+i5pjfjdEhyIHnJGl0JTwU6p
         4sAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1679213403;
        h=in-reply-to:content-disposition:mime-version:message-id:subject:to
         :from:date:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=0AIg6djfD3Z8OLbEjaJ/Dktvn8yVMGHT+GXUl6YhXpc=;
        b=LG6YwBRCn5c2HUOwfpffXRXEzVAEPZAYHaL0Q2Di+3Rggz9c81OhzNjTv3IR4S/akU
         HBtdqenxHnhfnkXPaWrrHm7ROV5IFc6UqAc0IHKrkr9Nr7f+xlYySh3VrzgTusqtTAuu
         RwE72o1TwdWZW3iL4uB/OSG+t7kzXMm02iS/D8++MDYYG29JaeNqqqQX7lCPyDn7kVM8
         7ogGJJ5jy26UhnHD5qc2AnU8IWHJFBkR3F65o4K2z3JdTgdN0WkNhCwNXB3+unPBopr6
         BL0f0H75oQBjNGdjviFbBHwjsCsFaxC/UshNG+h0kOtV5LkzaMMGTY+F/XE0QCEMa+4u
         L7uQ==
X-Gm-Message-State: AO0yUKWXDUjU7voW2IrR3/b7anZi1ycHTWIgNpk0fX+wrMH7AkC/2642
	Y+aQ6eiugxpqqzYoF6uHAWY=
X-Google-Smtp-Source: AK7set+16arltiftvfnV6BCmhAIkIEjIEDRUv+f7OoB0YUlTH+6h1Z0Z30okJuJMLxdoxhjKCGcTnQ==
X-Received: by 2002:a17:902:f685:b0:1a1:a727:a802 with SMTP id l5-20020a170902f68500b001a1a727a802mr8802172plg.19.1679213403275;
        Sun, 19 Mar 2023 01:10:03 -0700 (PDT)
Received: from sumitra.com ([117.212.94.33])
        by smtp.gmail.com with ESMTPSA id u6-20020a170902b28600b00194d14d8e54sm4340137plr.96.2023.03.19.01.09.59
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 19 Mar 2023 01:10:01 -0700 (PDT)
Date: Sun, 19 Mar 2023 01:09:55 -0700
From: Sumitra Sharma <sumitraartsy@gmail.com>
To: sumitraartsy@gmail.com, bagasdotme@gmail.com, julia.lawall@inria.fr,
	outreachy@lists.linux.dev
Subject: Re: your mail
Message-ID: <20230319080955.GA50179@sumitra.com>
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2123df9c-870-3a20-94b-7833bc66ad9@inria.fr>

On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
> 
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
> 
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email.  This is followed by some sections related to gmail,
> yahoo, etc.  So you could find the best place around there for the new
> information.
> 
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
> 

Actually, the only issue I faced was that the outreachyfirstpatch
document does not contain the information of how one can set their inbox in mutt.
Due to which I had problems to send and reply mails. This below
configuration update will enable the inbox at the client side.

How about this...

Under the section "Configure esmtp":

###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:

Note: The imap_pass, smtp_pass would be the App password or
 	  the mailbox password.

 		set sendmail="/usr/bin/esmtp"
 		set envelope_from=yes
 		set from="Your Name <my.email@gmail.com>"
 		set use_from=yes
 		set edit_headers=yes

 		# IMAP settings
 		set imap_user = "username@gmail.com"
 		set imap_pass = "<mailbox password>"

 		# SMTP settings
 		set smtp_url = "smtps://username@smtp.gmail.com"
 		set smtp_pass = "<mailbox password>"

 		# Remote Gmail folders
 		set folder = "imaps://imap.gmail.com/"
 		set spoolfile = "+INBOX"
 		set postponed = "+[Gmail]/Drafts"
 		set record = "+[Gmail]/Sent Mail"
 		set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup".  I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>

Okay! I will take care of it. Thank you.

In addition to this, I would like to bring to your notice that a hyperlink
in outrachyfirstpatch document, under the section "Git post-commit
hooks" does not work and it must be changed.

under Git post-commit hooks; checkpatch.pl:
http://lxr.free-electrons.com/source/scripts/checkpatch.pl
------------------------------------------------------------------
https://elixir.bootlin.com/linux/latest/source/scripts/checkpatch.pl




Regards,

Sumitra

> thanks,
> julia
> 
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B806A44
	for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 08:35:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=Rvm2jsgK+161Zahh8TTCEIp+evnc8Frj6KpxdnITrZU=;
  b=WQMzqaGC153QvaGF/Won1BSFmmYvw46qE08M+19/ioPi4PN13MS7P3kl
   ZG51QCwGuIlMF9mayBhTDnRRisLMEEIaY3giNkX9NxqbF3oDqiFNg4jBM
   U/fnGUhvhQhorMHg5hej/uJcYqCnbhS84K/ig6oG8mlJLNL9xQ8wyBm2y
   U=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.98,273,1673910000"; 
   d="scan'208";a="50598029"
Received: from 231.85.89.92.rev.sfr.net (HELO hadrien) ([92.89.85.231])
  by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2023 09:35:50 +0100
Date: Sun, 19 Mar 2023 09:35:50 +0100 (CET)
From: Julia Lawall <julia.lawall@inria.fr>
X-X-Sender: jll@hadrien
To: Sumitra Sharma <sumitraartsy@gmail.com>
cc: bagasdotme@gmail.com, outreachy@lists.linux.dev
Subject: Re: your mail
In-Reply-To: <20230319080955.GA50179@sumitra.com>
Message-ID: <alpine.DEB.2.22.394.2303190934200.2867@hadrien>
References: <20230319080955.GA50179@sumitra.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

> Actually, the only issue I faced was that the outreachyfirstpatch
> document does not contain the information of how one can set their inbox in mutt.
> Due to which I had problems to send and reply mails. This below
> configuration update will enable the inbox at the client side.
>
> How about this...
>
> Under the section "Configure esmtp":
>
> ###
> Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
>
> Note: The imap_pass, smtp_pass would be the App password or
>  	  the mailbox password.
>
>  		set sendmail="/usr/bin/esmtp"
>  		set envelope_from=yes
>  		set from="Your Name <my.email@gmail.com>"
>  		set use_from=yes
>  		set edit_headers=yes
>
>  		# IMAP settings
>  		set imap_user = "username@gmail.com"
>  		set imap_pass = "<mailbox password>"
>
>  		# SMTP settings
>  		set smtp_url = "smtps://username@smtp.gmail.com"
>  		set smtp_pass = "<mailbox password>"
>
>  		# Remote Gmail folders
>  		set folder = "imaps://imap.gmail.com/"
>  		set spoolfile = "+INBOX"
>  		set postponed = "+[Gmail]/Drafts"
>  		set record = "+[Gmail]/Sent Mail"
>  		set trash = "+[Gmail]/Trash"
> ###

Does this have anything to do with esmpt?

Does "<mailbox password>" mean that you have to put your password in plain
text?

julia

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A50510EC
	for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 08:56:18 +0000 (UTC)
Received: by mail-pj1-f47.google.com with SMTP id lr16-20020a17090b4b9000b0023f187954acso9497755pjb.2
        for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 01:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112; t=1679216178;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=JOgRsXHdFjRHqaXA5NIR424pWwIkiTWXGzkZHTu5nLQ=;
        b=ZDazINn54ZloBevmCKcTvs+4vHc1A6ViIPoxIMBetxXaS1mTgNwtL0aCHZQlJiBn1C
         ry4rxJCJzVOtHQrEmpeRHFcmulFDzybAf6NztnD+dPRZjX0s81+lBQtPAVK5ASD76PTf
         b9DmNKbZ8vtwu1WYRVQYLF9YhgPAc31UL0+pFMLtylQ86mlrs0Gazu/hXeTbo54WI7Jy
         sZlR5qJeXXlleoex9JDP7r0XIxUdGwWvbRrH/zEKIidR0TzmsE7OuuqeEkYaXHqnVjzM
         g0EB6vt0Z1hqePML9ZEChAesDMzuc58cYm2+OFfktQt0XlBe8eS+aomOy3yONTKlQ2HQ
         mIgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1679216178;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JOgRsXHdFjRHqaXA5NIR424pWwIkiTWXGzkZHTu5nLQ=;
        b=YhBdDwaRrMHsc4PS7+wQdInc07VIdhcNyojfsbRvqph+bR/VZJeHzeFH/Nxhzrbo+z
         4OjIs6Vsro32P1vuQFAE+7Cy+guioszf0Gd00vXV28z1yS0EtTPxvJvu63XuEUxEl7kX
         FNV8Igxku9+AU7JYaP9JaK285nrRzr4R7JtZ+oEk7i5hE3vx7muEoGhWhfcN8hU2fJws
         FpNB++5AzDeAxDfh2RyqB0QDvyathS19c5l+vRXktf72YA1ZJ2/LPObFqAHxn1T60Awu
         GOc8p5z19x8TiT3yZCeL4WqZbEmjxdA+Fp6jFasSEPInswpLK06zDdPyrD0pn7uOT+N0
         SiQA==
X-Gm-Message-State: AO0yUKW8ibWm/DxkZRrKwt9RYWJbRWU+qxFdHvf0Vc1gDrj0MuzkT27Q
	/59Fk63fMGDet6Lx9aJZJmA=
X-Google-Smtp-Source: AK7set/BXol1JQpxZylp8/ahsoNyfW2Y1SvPksXT+qmm0Dd2d34wjnUF9uRFpa66X+06byX7qq3KPw==
X-Received: by 2002:a05:6a20:3b9f:b0:d9:2cef:949f with SMTP id b31-20020a056a203b9f00b000d92cef949fmr1327240pzh.40.1679216177731;
        Sun, 19 Mar 2023 01:56:17 -0700 (PDT)
Received: from sumitra.com ([117.212.94.33])
        by smtp.gmail.com with ESMTPSA id bs187-20020a6328c4000000b0050f74d435e6sm350425pgb.18.2023.03.19.01.56.15
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 19 Mar 2023 01:56:17 -0700 (PDT)
Date: Sun, 19 Mar 2023 01:56:12 -0700
From: Sumitra Sharma <sumitraartsy@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: bagasdotme@gmail.com, outreachy@lists.linux.dev
Subject: Re: your mail
Message-ID: <20230319085612.GD50179@sumitra.com>
References: <20230319080955.GA50179@sumitra.com>
 <alpine.DEB.2.22.394.2303190934200.2867@hadrien>
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2303190934200.2867@hadrien>

On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > Actually, the only issue I faced was that the outreachyfirstpatch
> > document does not contain the information of how one can set their inbox in mutt.
> > Due to which I had problems to send and reply mails. This below
> > configuration update will enable the inbox at the client side.
> >
> > How about this...
> >
> > Under the section "Configure esmtp":
> >
> > ###
> > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> >
> > Note: The imap_pass, smtp_pass would be the App password or
> >  	  the mailbox password.
> >
> >  		set sendmail="/usr/bin/esmtp"
> >  		set envelope_from=yes
> >  		set from="Your Name <my.email@gmail.com>"
> >  		set use_from=yes
> >  		set edit_headers=yes
> >
> >  		# IMAP settings
> >  		set imap_user = "username@gmail.com"
> >  		set imap_pass = "<mailbox password>"
> >
> >  		# SMTP settings
> >  		set smtp_url = "smtps://username@smtp.gmail.com"
> >  		set smtp_pass = "<mailbox password>"
> >
> >  		# Remote Gmail folders
> >  		set folder = "imaps://imap.gmail.com/"
> >  		set spoolfile = "+INBOX"
> >  		set postponed = "+[Gmail]/Drafts"
> >  		set record = "+[Gmail]/Sent Mail"
> >  		set trash = "+[Gmail]/Trash"
> > ###
> 
> Does this have anything to do with esmpt?
>

In the current version of the outreachy firstpatch document the configuration 
steps for .esmtp and .muttrc are written under the heading
"Configure esmtp" and also to configure esmtp we are creating the muttrc
file. So, both are linked in a way.

> Does "<mailbox password>" mean that you have to put your password in plain
> text?
> 

Yes, but it is always prefered to use the app password for better security.


Regards,

Sumitra

> julia

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2013310EC
	for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 09:02:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=Ukm8dSqGOWpoJwHSWY019Qn+Q/OtHQ+9Jf6Du/QX7Eo=;
  b=Bh9RFDVE8dnuPBzpbMbjrfa7FM6abf4i5257S3WU8+4KbQzZfsIrHimf
   ZJ6eO8WST1CqZI1/qTaicpFMpivLRCMQZ7XBcbcu6IDqMAd3RL8mUrChq
   ae1tID0RnMCAvGGK8arXZ/1KYwWxNN/foj5Vx2W3WOHJ6ccKj4N3/OCjf
   Y=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.98,273,1673910000"; 
   d="scan'208";a="50599408"
Received: from 231.85.89.92.rev.sfr.net (HELO hadrien) ([92.89.85.231])
  by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2023 10:02:47 +0100
Date: Sun, 19 Mar 2023 10:02:46 +0100 (CET)
From: Julia Lawall <julia.lawall@inria.fr>
X-X-Sender: jll@hadrien
To: Sumitra Sharma <sumitraartsy@gmail.com>
cc: bagasdotme@gmail.com, outreachy@lists.linux.dev
Subject: Re: your mail
In-Reply-To: <20230319085612.GD50179@sumitra.com>
Message-ID: <alpine.DEB.2.22.394.2303190956470.2867@hadrien>
References: <20230319080955.GA50179@sumitra.com> <alpine.DEB.2.22.394.2303190934200.2867@hadrien> <20230319085612.GD50179@sumitra.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII



On Sun, 19 Mar 2023, Sumitra Sharma wrote:

> On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > document does not contain the information of how one can set their inbox in mutt.
> > > Due to which I had problems to send and reply mails. This below
> > > configuration update will enable the inbox at the client side.
> > >
> > > How about this...
> > >
> > > Under the section "Configure esmtp":
> > >
> > > ###
> > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > >
> > > Note: The imap_pass, smtp_pass would be the App password or
> > >  	  the mailbox password.
> > >
> > >  		set sendmail="/usr/bin/esmtp"
> > >  		set envelope_from=yes
> > >  		set from="Your Name <my.email@gmail.com>"
> > >  		set use_from=yes
> > >  		set edit_headers=yes
> > >
> > >  		# IMAP settings
> > >  		set imap_user = "username@gmail.com"
> > >  		set imap_pass = "<mailbox password>"
> > >
> > >  		# SMTP settings
> > >  		set smtp_url = "smtps://username@smtp.gmail.com"
> > >  		set smtp_pass = "<mailbox password>"
> > >
> > >  		# Remote Gmail folders
> > >  		set folder = "imaps://imap.gmail.com/"
> > >  		set spoolfile = "+INBOX"
> > >  		set postponed = "+[Gmail]/Drafts"
> > >  		set record = "+[Gmail]/Sent Mail"
> > >  		set trash = "+[Gmail]/Trash"
> > > ###
> >
> > Does this have anything to do with esmpt?
> >
>
> In the current version of the outreachy firstpatch document the configuration
> steps for .esmtp and .muttrc are written under the heading
> "Configure esmtp" and also to configure esmtp we are creating the muttrc
> file. So, both are linked in a way.

I don't think so.  Comfiguring esmtp requires adding some information to
the .muttrc, but people who don't want to configure esmtp may also want to
add information to the .muttrc.

>
> > Does "<mailbox password>" mean that you have to put your password in plain
> > text?
> >
>
> Yes, but it is always prefered to use the app password for better security.

The existing text about sending mesages with mutt says:

identity "my.email@gmail.com"
hostname smtp.gmail.com:587
username "my.email@gmail.com"
password "ThisIsNotARealPassWord"
starttls required

Why not put "ThisIsNotARealPassWord" in your text as well, if that is
what you expect people to do?

That is, when you put something in quotes, the reader doedn't know whether
they are supposed to put exactly the thing that you have put in the quotes
or something else.  I guess that for eg "smtps://username@smtp.gmail.com"
they should fill in their real username.  But for "<mailbox password>" it
is not clear what is expected.

julia

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F13310EC
	for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 09:53:35 +0000 (UTC)
Received: by mail-pl1-f172.google.com with SMTP id w4so1538509plg.9
        for <outreachy@lists.linux.dev>; Sun, 19 Mar 2023 02:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112; t=1679219615;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=gSyHXg+qx54UG3oTV3mgfkfkktN+bMfa4iTfcRiiiac=;
        b=GeFOWxcvNMzk+b1G/ECAgiBJCPdUvjz/5blvXTrmnDYq2kYT+QIj/JXnWsvHA3o3QK
         NPxpLKfyJKOH1nyObiW8cTJpfFufur9vsdlCELGYFl9rmgMslmrxFCQH4vFyAn+seqh0
         J30aOWEhuAgwX+yIyUqQOCvhWqdAkKV6Y4X6gTdd9nVi131moaKj0wVXmvBNHIsUgHsp
         DP3HCIs19DffZLy9k+ZT/u/Zuqu5iQw3nmrKa5Bto9jL5nen8OkNiSy+Jsmwh2ZQ+3R0
         6df1EGxf7bTCL9vjk9p5uRe9qh9MQjKdZqwmgyrh9qnLFoeqrbCdwPEiRM9kpP1+CFOl
         LIsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1679219615;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gSyHXg+qx54UG3oTV3mgfkfkktN+bMfa4iTfcRiiiac=;
        b=5kLo9UtuQlKxgnCMV/i8mDynvj3ATtkiCZoH/XGJRxbvs0r4MKFDvSbRSJOm2a7qKh
         OTufpPPKcN0fbC7e96FfvyUXYq0fo60t0cV27iOxelT43t7Wz5dho2ox4cltqMCB7zlY
         qlBkMma/9TB//LEJAmZjfZKUD9CYEtl+U6lgcBTeevJ/iSRSLlD+vUqLlzM+A2ZlBBxh
         f5KnOTlBIodObBqBp7b0IMwQGAJ8on3+LpsOJV2u50KG4+Midr0Fm9P13t+QhMLj9L48
         J6VC4y0op59yTzRonFWnzLrmQxkz65ZKD5aZW8gVc+CTRiZcLPmyBJxZEuEg8nD8HGi/
         7Yug==
X-Gm-Message-State: AO0yUKUu7IB0smxENEhxZsoL27wgzXl1uQzclpa3MwGjHhPdGtLthpzf
	ZLCay+hG3X3WjU7e7YD3vEg=
X-Google-Smtp-Source: AK7set+dDt0mz2hQGHeQDtciKQs3LmKtdWeoc4fQ6FmcDLsvKjvdKWuNq8gRfKVnEe/1cfOJYlC6Gg==
X-Received: by 2002:a17:902:e0d1:b0:1a0:459b:3276 with SMTP id e17-20020a170902e0d100b001a0459b3276mr10305863pla.11.1679219614552;
        Sun, 19 Mar 2023 02:53:34 -0700 (PDT)
Received: from sumitra.com ([117.212.94.33])
        by smtp.gmail.com with ESMTPSA id c24-20020a170902849800b0019f27fd7cecsm4458409plo.197.2023.03.19.02.53.31
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 19 Mar 2023 02:53:33 -0700 (PDT)
Date: Sun, 19 Mar 2023 02:53:28 -0700
From: Sumitra Sharma <sumitraartsy@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: bagasdotme@gmail.com, outreachy@lists.linux.dev
Subject: Re: your mail
Message-ID: <20230319095328.GE50179@sumitra.com>
References: <20230319080955.GA50179@sumitra.com>
 <alpine.DEB.2.22.394.2303190934200.2867@hadrien>
 <20230319085612.GD50179@sumitra.com>
 <alpine.DEB.2.22.394.2303190956470.2867@hadrien>
Precedence: bulk
X-Mailing-List: outreachy@lists.linux.dev
List-Id: <outreachy.lists.linux.dev>
List-Subscribe: <mailto:outreachy+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:outreachy+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2303190956470.2867@hadrien>

On Sun, Mar 19, 2023 at 10:02:46AM +0100, Julia Lawall wrote:
> 
> 
> On Sun, 19 Mar 2023, Sumitra Sharma wrote:
> 
> > On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > > document does not contain the information of how one can set their inbox in mutt.
> > > > Due to which I had problems to send and reply mails. This below
> > > > configuration update will enable the inbox at the client side.
> > > >
> > > > How about this...
> > > >
> > > > Under the section "Configure esmtp":
> > > >
> > > > ###
> > > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > > >
> > > > Note: The imap_pass, smtp_pass would be the App password or
> > > >  	  the mailbox password.
> > > >
> > > >  		set sendmail="/usr/bin/esmtp"
> > > >  		set envelope_from=yes
> > > >  		set from="Your Name <my.email@gmail.com>"
> > > >  		set use_from=yes
> > > >  		set edit_headers=yes
> > > >
> > > >  		# IMAP settings
> > > >  		set imap_user = "username@gmail.com"
> > > >  		set imap_pass = "<mailbox password>"
> > > >
> > > >  		# SMTP settings
> > > >  		set smtp_url = "smtps://username@smtp.gmail.com"
> > > >  		set smtp_pass = "<mailbox password>"
> > > >
> > > >  		# Remote Gmail folders
> > > >  		set folder = "imaps://imap.gmail.com/"
> > > >  		set spoolfile = "+INBOX"
> > > >  		set postponed = "+[Gmail]/Drafts"
> > > >  		set record = "+[Gmail]/Sent Mail"
> > > >  		set trash = "+[Gmail]/Trash"
> > > > ###
> > >
> > > Does this have anything to do with esmpt?
> > >
> >
> > In the current version of the outreachy firstpatch document the configuration
> > steps for .esmtp and .muttrc are written under the heading
> > "Configure esmtp" and also to configure esmtp we are creating the muttrc
> > file. So, both are linked in a way.
> 
> I don't think so.  Comfiguring esmtp requires adding some information to
> the .muttrc, but people who don't want to configure esmtp may also want to
> add information to the .muttrc.
>

Then, why dont we rename the section as "Configure MTA"

then it will go as follows:

> >
> > > Does "<mailbox password>" mean that you have to put your password in plain
> > > text?
> > >
> >
> > Yes, but it is always prefered to use the app password for better security.
> 
> The existing text about sending mesages with mutt says:
> 
> identity "my.email@gmail.com"
> hostname smtp.gmail.com:587
> username "my.email@gmail.com"
> password "ThisIsNotARealPassWord"
> starttls required
> 
> Why not put "ThisIsNotARealPassWord" in your text as well, if that is
> what you expect people to do?
> 
> That is, when you put something in quotes, the reader doedn't know whether
> they are supposed to put exactly the thing that you have put in the quotes
> or something else.  I guess that for eg "smtps://username@smtp.gmail.com"
> they should fill in their real username.  But for "<mailbox password>" it
> is not clear what is expected.
> 

###
Configure MTA

Note: These instructions assume you're using esmtp, but if you already have another mail transfer agent (MTA) installed, you do not need to install esmtp. Instead, change the .muttrc file "sendmail" line to be the path to your MTA. Mutt uses ssmtp by default, so if your MTA is ssmtp, you can leave that line out entirely.

First, create a .esmtprc file with the right permissions:


			touch ~/.esmtprc
			chmod g-rwx ~/.esmtprc
			chmod o-rwx ~/.esmtprc

Edit the .esmtprc in your home directory, and add lines like this:

			identity "my.email@gmail.com"
			hostname smtp.gmail.com:587
			username "my.email@gmail.com"
			password "ThisIsNotARealPassWord"
			starttls required 

(For Yahoo mail, replace hostname line with:

			hostname smtp.mail.yahoo.com:587

Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
 Note: The imap_pass, smtp_pass would be the App password or the mailbox password.


	           set sendmail="/usr/bin/esmtp"
	           set envelope_from=yes
	           set from="Your Name <my.email@gmail.com>"
	           set use_from=yes
		     set edit_headers=yes

                 # IMAP settings
                 set imap_user = "username@gmail.com"
                 set imap_pass = "<ThisIsNotARealPassWord>"

                 # SMTP settings
                 set smtp_url = "smtps://username@smtp.gmail.com"
                 set smtp_pass = "<ThisIsNotARealPassWord>"

                 # Remote Gmail folders
                 set folder = "imaps://imap.gmail.com/"
                 set spoolfile = "+INBOX"
                 set postponed = "+[Gmail]/Drafts"
                 set record = "+[Gmail]/Sent Mail"
                 set trash = "+[Gmail]/Trash"


###


Regards,

Sumitra

> julia

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Subject: Re: your mail
Date: Fri, 18 Aug 2017 23:23:02 +0530
Message-ID: <20170818175301.GA12806@raj-desk2.iind.intel.com>
References: <20170818174214.GA12519@raj-desk2.iind.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20170818174214.GA12519@raj-desk2.iind.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>, Platform Driver <platform-driver-x86@vger.kernel.org>, "dvhart@infradead.org" <dvhart@infradead.org>, Andy Shevchenko <andy@infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Vishwanath Somayaji <vishwanath.somayaji@intel.com>, dbasehore@chromium.org, rjw@rjwysocki.net, rajatja@google.com
List-Id: platform-driver-x86.vger.kernel.org

On Fri, Aug 18, 2017 at 11:12:14PM +0530, Rajneesh Bhardwaj wrote:
> Bcc: 
> Subject: Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states
>  residency info
> Reply-To: 
> In-Reply-To: <CAHp75Vd5Wnio-RCEBENtonYWOJF2+88FDvqkUv1HzV3CdcaaPA@mail.gmail.com>
>

Please ignore my previous email without subject. It was sent by mistake.

> On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote:
> > +PeterZ (since I mentioned his name)
> > 
> > On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj
> > <rajneesh.bhardwaj@intel.com> wrote:
> > > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shevchenko wrote:
> > >> On Fri, Aug 18, 2017 at 3:37 PM, Rajneesh Bhardwaj
> > >> <rajneesh.bhardwaj@intel.com> wrote:
> > >> > This patch introduces a new debugfs entry to read current Package C-state
> > >> > residency values and, one new kernel API to read the Package C-10 residency
> > >> > counter.
> > >> >
> > >> > Package C-state residency MSRs provide useful debug information about system
> > >> > idle states. In idle states system must enter deeper Package C-states.
> > 
> > >> Why this patch is needed?
> > >
> > > Andy, I'll try to give some background for this.
> > >
> > > This is needed to enhance the S0ix failure debug capabilities from within
> > > the kernel. On ChromeOS we have S0ix failsafe kernel framework that is used
> > > to validate S0ix and report the blockers in case of a failure.
> > > https://patchwork.kernel.org/patch/9148999/
> > 
> > (It's not part of upstream)
> 
> Sorry i sent an older link. There are fresh attempts to get this into
> mainline kernel and looks like there is a traction for it.
> https://patchwork.kernel.org/patch/9831229/
> 
> Package C-state (PC10) validation is discussed there.
> 
> > 
> > > So far only intel_pmc_slp_s0_counter_read is called by this framework to
> > > check whether the previous attempt to enter S0ix was success or not.
> > 
> > I harder see even a single user of that API in current kernel. It
> > should be unexported and removed I think.
> > 
> > >  Having
> > > another PC10 counter related exported function enhances the S0ix debug since
> > > PC10 state is a prerequisite to enter S0ix.
> > >
> > >> See, we have turbostat and cpupower user space tools which do this
> > >> without any additional code to be written in kernel. What prevents
> > >> your user space application do the same?
> > >>
> > >> Moreover, we have events for cstate, I assume perf or something alike
> > >> can monitor those counters as well.
> > >
> > > You're right, perhaps the debugfs is redundant when we have those user space
> > > tools but such tools are not available readily for all platforms/distros.
> > > Interfaces like /dev/cpu/*/msr that turbostat uses are not available on all
> > > the platforms.
> > > PMC driver is a debug driver so i thought its better to show Package C-state
> > > related info for low power debug here.
> > >
> > >>
> > >> Sorry, NAK.
> > >
> > > This patch has two parts i.e. exported PC10 API and the debugfs. Based on
> > > the above explanation, if the patch is not good as is, please let me know if
> > > i should drop the debugfs part and respin a v2 with just the exported API or
> > > drop this totally.
> > >
> > > Thanks for the feedback and thanks for taking time to review!
> > 
> > Reading above makes me think that entire design of this is misguided.
> > Since the most of values are counters they better to be accessed in a
> > way how perf does.
> > 
> > In case you need *in-kernel* facility, do some APIs (if it's not done
> > yet) for events drivers first.
> > cstate event driver is already in upstream.
> > 
> > Sorry, NAK for entire patch until it would be blessed by people like Peter Z.
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko
> 
> -- 
> Best Regards,
> Rajneesh

-- 
Best Regards,
Rajneesh

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: your mail
Date: Mon, 11 May 2020 14:44:20 +0300
Message-ID: <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
References: <526351589195104@mail.yandex.com> <20200511113506.GB2062175@kuha.fi.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Return-path: <linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
In-Reply-To: <20200511113506.GB2062175-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Heikki Krogerus <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: jakub-FiUXBBwNs2Q@public.gmane.org, Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Platform Driver <platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
List-Id: platform-driver-x86.vger.kernel.org

+Cc: Hans

On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
<heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> +Andy
>
> Adding also the linux-usb mailing list.
>
> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub-FiUXBBwNs2Q@public.gmane.org wrote:
> > Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> > with cpu interrups causing issues with deeper CPU sleep and increased power
> > usage. Also load is always 1 even if machine has nothing to do.
> >
> > I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> > device is related with USB and according to datasheet it's "USB Interface IC USB
> > Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> > nothing connected to NUC except power plug and ethernet cable.
> >
> > Screenshots: https://imgur.com/a/uw9NDCi
> >
> > How to solve this issue? Could you help me?
>
> My guess is that the IRQ resource is not correct for the PD
> controller causing you to see irq flood.
>
> The problem is that the ACPI device entry (the node) on this platform
> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
> single ACPI device entry can represent up to 4 USB PD controllers. The
> problem is that there is no way to know which IRQ resource belongs to
> which I2CSerialBus resource :-(.
>
> Andy, this is one of those multi-instantiate I2C slave devices with
> HID INT3515.
>
> The only solution I can think of is that we start maintaining DMI
> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
> supply the correct i2c to irq resource mapping for every platform
> that has this device(s).

I would rather disable them and issue a firmware bug.
Vendors, including us, should do something sane about this.

> > Kernel version:
> >
> > Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > Bios version:
> > FNCML357 Version: 0039 Date: 3/12/2020

-- 
With Best Regards,
Andy Shevchenko

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: your mail
Date: Mon, 11 May 2020 14:29:24 +0200
Message-ID: <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
References: <526351589195104@mail.yandex.com>
 <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
In-Reply-To: <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-Language: en-US
Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Heikki Krogerus <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: jakub-FiUXBBwNs2Q@public.gmane.org, Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Platform Driver <platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
List-Id: platform-driver-x86.vger.kernel.org

Hi,

On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> +Cc: Hans

Thank you, I'm afraid that I do not have much of value
to add here, Heikki knows these systems (with an INT3515 device)
a lot better then I do.

> On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
> <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>
>> +Andy
>>
>> Adding also the linux-usb mailing list.
>>
>> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub-FiUXBBwNs2Q@public.gmane.org wrote:
>>> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
>>> with cpu interrups causing issues with deeper CPU sleep and increased power
>>> usage. Also load is always 1 even if machine has nothing to do.
>>>
>>> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
>>> device is related with USB and according to datasheet it's "USB Interface IC USB
>>> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
>>> nothing connected to NUC except power plug and ethernet cable.
>>>
>>> Screenshots: https://imgur.com/a/uw9NDCi
>>>
>>> How to solve this issue? Could you help me?
>>
>> My guess is that the IRQ resource is not correct for the PD
>> controller causing you to see irq flood.
>>
>> The problem is that the ACPI device entry (the node) on this platform
>> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
>> single ACPI device entry can represent up to 4 USB PD controllers. The
>> problem is that there is no way to know which IRQ resource belongs to
>> which I2CSerialBus resource :-(.
>>
>> Andy, this is one of those multi-instantiate I2C slave devices with
>> HID INT3515.
>>
>> The only solution I can think of is that we start maintaining DMI
>> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
>> supply the correct i2c to irq resource mapping for every platform
>> that has this device(s).
> 
> I would rather disable them and issue a firmware bug.
> Vendors, including us, should do something sane about this.

I have to partially disagree here. I agree that for future hardware
versions the firmware team of those devices should offer a saner
interface. But for the current hardware gen I guess we are stuck
with this and having a DMI table for popular models (well any model
a Linux user is willing to submit a quirk for) is better then simply
not having things working under Linux.

I do wonder what Windows does here though. Perhaps the INT3513 device
has some ACPI methods to query for more info, like how many Type-C
controllers there actually are?

Regards,

Hans

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: your mail
Date: Mon, 11 May 2020 16:40:05 +0300
Message-ID: <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw@mail.gmail.com>
References: <526351589195104@mail.yandex.com> <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com> <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Return-path: <linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
In-Reply-To: <5ee2b9ef-25e3-c049-3f82-d3d51d392824-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Heikki Krogerus <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, jakub-FiUXBBwNs2Q@public.gmane.org, Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Platform Driver <platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
List-Id: platform-driver-x86.vger.kernel.org

On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 5/11/20 1:44 PM, Andy Shevchenko wrote:

...

> > I would rather disable them and issue a firmware bug.
> > Vendors, including us, should do something sane about this.
>
> I have to partially disagree here. I agree that for future hardware
> versions the firmware team of those devices should offer a saner
> interface. But for the current hardware gen I guess we are stuck
> with this and having a DMI table for popular models (well any model
> a Linux user is willing to submit a quirk for) is better then simply
> not having things working under Linux.
>
> I do wonder what Windows does here though. Perhaps the INT3513 device
> has some ACPI methods to query for more info, like how many Type-C
> controllers there actually are?

I think they do silly things there in usual obscure MS way, i.e.
hardcoding everything in the driver per platform.
That's why I'm really disappointed how things are going on.

-- 
With Best Regards,
Andy Shevchenko

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Heikki Krogerus <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: your mail
Date: Mon, 18 May 2020 16:35:30 +0300
Message-ID: <20200518133530.GB1298122@kuha.fi.intel.com>
References: <526351589195104@mail.yandex.com>
 <20200511113506.GB2062175@kuha.fi.intel.com>
 <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ@mail.gmail.com>
 <5ee2b9ef-25e3-c049-3f82-d3d51d392824@redhat.com>
 <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: jakub-FiUXBBwNs2Q@public.gmane.org
Cc: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Platform Driver <platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
List-Id: platform-driver-x86.vger.kernel.org

Hi Jakub,

On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote:
> On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> 
> ...
> 
> > > I would rather disable them and issue a firmware bug.
> > > Vendors, including us, should do something sane about this.
> >
> > I have to partially disagree here. I agree that for future hardware
> > versions the firmware team of those devices should offer a saner
> > interface. But for the current hardware gen I guess we are stuck
> > with this and having a DMI table for popular models (well any model
> > a Linux user is willing to submit a quirk for) is better then simply
> > not having things working under Linux.
> >
> > I do wonder what Windows does here though. Perhaps the INT3513 device
> > has some ACPI methods to query for more info, like how many Type-C
> > controllers there actually are?
> 
> I think they do silly things there in usual obscure MS way, i.e.
> hardcoding everything in the driver per platform.
> That's why I'm really disappointed how things are going on.

I've been trying to figure out which exact NUC10i3 your NUC is? I
can't find a NUC10i3 that uses Comet Lake -S?

If your NUC isn't actually "-S" variant, then the ACPI device entry
with HID INT3515 should return 0 from its _STA method.

But can you please share the full name of your board (like NUC10i3FNH
or something like that - should read on the bottom of the device).
Also, dmesg output would be useful.

thanks,

-- 
heikki

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Rostedt <rostedt@goodmis.org>
Subject: Re: your mail
Date: Mon, 24 Sep 2007 16:50:06 -0400 (EDT)
Message-ID: <Pine.LNX.4.58.0709241649220.11726@gandalf.stny.rr.com>
References: <20070924204408.GA4748@goodmis.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	linux-rt-users@vger.kernel.org
To: Jaswinder Singh <jaswinderlinux@gmail.com>
Return-path: <linux-rt-users-owner@vger.kernel.org>
Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]:59603 "EHLO
	ms-smtp-02.nyroc.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751805AbXIXUuM (ORCPT
	<rfc822;linux-rt-users@vger.kernel.org>);
	Mon, 24 Sep 2007 16:50:12 -0400
In-Reply-To: <20070924204408.GA4748@goodmis.org>
Sender: linux-rt-users-owner@vger.kernel.org
List-Id: linux-rt-users.vger.kernel.org



--
On Mon, 24 Sep 2007, Steven Rostedt wrote:

> linux-rt-users@vger.kernel.org
> Bcc:
> Subject: Re: realtime preemption performance difference
> Reply-To:
> In-Reply-To: <3f9a31f40709240448h4a9e8337t437328b5c675ecd5@mail.gmail.com>

[ I'm actually just learning how to screw-up^Wuse mutt ]

bah!

-- Steve

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Lameter <cl@linux.com>
Subject: (unknown)
Date: Tue, 15 Nov 2016 14:29:16 -0600 (CST)
Message-ID: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
Content-Type: text/plain; charset=US-ASCII
Cc: Daniel Vacek <neelx.g@gmail.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Return-path: <linux-rt-users-owner@vger.kernel.org>
Received: from resqmta-ch2-01v.sys.comcast.net ([69.252.207.33]:44758 "EHLO
        resqmta-ch2-01v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751937AbcKOU3P (ORCPT
        <rfc822;linux-rt-users@vger.kernel.org>);
        Tue, 15 Nov 2016 15:29:15 -0500
Sender: linux-rt-users-owner@vger.kernel.org
List-ID: <linux-rt-users.vger.kernel.org>


> > There is a deadlock, Peter!!!
>
> Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
>


The description was given earlier in the the thread and the drawbacks of
using RT_RUNTIME_SHARE as well.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Rostedt <rostedt@goodmis.org>
Subject: Re: ???
Date: Tue, 15 Nov 2016 16:58:36 -0500
Message-ID: <20161115165836.2202a9a6@gandalf.local.home>
References: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Peter Zijlstra <peterz@infradead.org>,
        Daniel Vacek <neelx.g@gmail.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>
To: Christoph Lameter <cl@linux.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-rt-users.vger.kernel.org


What's with people sending out replies without subjects?

On Tue, 15 Nov 2016 14:29:16 -0600 (CST)
Christoph Lameter <cl@linux.com> wrote:

> > > There is a deadlock, Peter!!!  
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >  
> 
> 
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.

Peter is saying to disable that, because of the drawbacks. I think the
question is, do you still have a deadlock after disabling it? If not,
then that's your solution.

-- Steve

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: your mail
Date: Wed, 16 Nov 2016 11:40:14 +0100
Message-ID: <20161116104014.GQ3142@twins.programming.kicks-ass.net>
References: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Daniel Vacek <neelx.g@gmail.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>
To: Christoph Lameter <cl@linux.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-rt-users.vger.kernel.org

On Tue, Nov 15, 2016 at 02:29:16PM -0600, Christoph Lameter wrote:
> 
> > > There is a deadlock, Peter!!!
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >
> 
> 
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.

I've not seen a deadlock described. It either was an unbounded priority
inversion or a starvation issue, both of which are 'design' features of
the !rt kernel.

Neither things are new, so its not a regression either.

And, as stated, I'm not really happy to muck with this known troublesome
code and add features for which we must then maintain feature parity
when replacing it either.

On top of which, the implementation had issues; now I know you're the
blinder kind of person that disregards everything not in his immediate
interest, but if you'd looked at the patch you'd have seen he'd added
code the idle entry path, which will slow down every single to-idle
transition.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Rostedt <rostedt@goodmis.org>
Subject: Re: your mail
Date: Wed, 16 Nov 2016 09:25:43 -0500
Message-ID: <20161116092543.663e1d2c@gandalf.local.home>
References: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
        <20161116104014.GQ3142@twins.programming.kicks-ass.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Christoph Lameter <cl@linux.com>, Daniel Vacek <neelx.g@gmail.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Return-path: <linux-rt-users-owner@vger.kernel.org>
Received: from smtprelay0016.hostedemail.com ([216.40.44.16]:45996 "EHLO
        smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1751277AbcKPOZr (ORCPT
        <rfc822;linux-rt-users@vger.kernel.org>);
        Wed, 16 Nov 2016 09:25:47 -0500
In-Reply-To: <20161116104014.GQ3142@twins.programming.kicks-ass.net>
Sender: linux-rt-users-owner@vger.kernel.org
List-ID: <linux-rt-users.vger.kernel.org>

On Wed, 16 Nov 2016 11:40:14 +0100
Peter Zijlstra <peterz@infradead.org> wrote:


> On top of which, the implementation had issues; now I know you're the
> blinder kind of person that disregards everything not in his immediate
> interest, but if you'd looked at the patch you'd have seen he'd added
> code the idle entry path, which will slow down every single to-idle
> transition.

Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
there was some issues with idle_balance() which can add latency to
wakeups. idle_balance() is also in the to-idle path.

Note, that this is a sched feature which would be a nop (jump_label)
when disabled. And I'm sure it could also be optimized to be a static
inline as well when it is enabled.

I'm not saying we need to go this approach, but I'm just saying that
the to-idle issue is a bit of a red herring.

-- Steve

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: your mail
Date: Wed, 16 Nov 2016 15:28:21 +0100
Message-ID: <20161116142821.GZ3117@twins.programming.kicks-ass.net>
References: <alpine.DEB.2.20.1611151428190.28591@east.gentwo.org>
 <20161116104014.GQ3142@twins.programming.kicks-ass.net>
 <20161116092543.663e1d2c@gandalf.local.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Christoph Lameter <cl@linux.com>, Daniel Vacek <neelx.g@gmail.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20161116092543.663e1d2c@gandalf.local.home>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-rt-users.vger.kernel.org

On Wed, Nov 16, 2016 at 09:25:43AM -0500, Steven Rostedt wrote:
> On Wed, 16 Nov 2016 11:40:14 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> 
> > On top of which, the implementation had issues; now I know you're the
> > blinder kind of person that disregards everything not in his immediate
> > interest, but if you'd looked at the patch you'd have seen he'd added
> > code the idle entry path, which will slow down every single to-idle
> > transition.
> 
> Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
> there was some issues with idle_balance() which can add latency to
> wakeups. idle_balance() is also in the to-idle path.
> 

Yes it is too heavy as is, but just stacking more crap in just because
its already expensive seems to wrong way around.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 23 Mar 2001 20:53:35 -0500 (EST)
From: Chris Crowther <shadow@shad0w.org>
To: SELinux@tycho.nsa.gov
Subject: Re: your mail
In-Reply-To: <OFC8827216.E70119F9-ON85256A18.007CF1F0@pok.ibm.com>
Message-ID: <Pine.LNX.4.21.0103232050440.28046-100000@monolith.sanctum.shad0w.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov

On Fri, 23 Mar 2001, Hubertus Franke wrote:

> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?

	The header files get auto-created by the build, but they're not
there when make dep is run, so you get all the errors, but the Kernel does
compile.

-- 
Chris "_Shad0w_" Crowther
shad0w@shad0w.org
http://www.shad0w.org.uk/



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: gawain.lynch@felicity-consulting.com.au
To: Chris Crowther <shadow@shad0w.org>
Cc: owner-selinux@tycho.nsa.gov, SELinux@tycho.nsa.gov
Subject: Re: your mail
MIME-Version: 1.0
Message-ID: <OF80957966.799B47D4-ONCA256A19.001AABA7@felicity.net.au>
Date: Sat, 24 Mar 2001 15:55:24 +1100
Content-Type: text/plain; charset="us-ascii"
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov

> > /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> > linux/flask/flask.h: No such file or directory
> > /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> > config/flask/audit.h: No such file or directory
> > 
> > Looks like various files are missing in the distribution.
> > Any ideas ?

>                The header files get auto-created by the build, but 
they're not
> there when make dep is run, so you get all the errors, but the Kernel 
does
> compile.

I am having the same issue with the current release, I let 
tool/build-kernel run twice, but both times it exits with the error below:

        In file included from /usr/include/errno.h:36,
                         from scripts/split-include.c:26:
        /usr/include/bits/errno.h:25: linux/errno.h: No such file or 
directory
        make: *** [scripts/split-include] Error 1

I have also tried patching fresh source here and I get the same issues.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 23 Mar 2001 23:26:49 -0800 (PST)
From: "frenzy@frenzy.org" <mcclellr@OIT.EDU>
cc: SELinux@tycho.nsa.gov
Subject: Re: your mail
In-Reply-To: <OFC8827216.E70119F9-ON85256A18.007CF1F0@pok.ibm.com>
Message-ID: <Pine.OSF.4.02.10103232325100.16137-100000@internet.oit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov

It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,

Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see 
in the world." - Mahatma Gandhi   
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt

On Fri, 23 Mar 2001, Hubertus Franke wrote:

just downloaded the SELinux for 2.4.

I did the ./tools/build-kernel  and get the following errors.


/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory


/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory

Looks like various files are missing in the distribution.
Any ideas ?


Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Subject: Re: your mail
To: "frenzy@frenzy.org" <mcclellr@OIT.EDU>
Cc: SELinux@tycho.nsa.gov
Message-ID: <OF73C8A883.7BE9BE45-ON85256A19.00676A3B@pok.ibm.com>
From: "Hubertus Franke" <frankeh@us.ibm.com>
Date: Sat, 24 Mar 2001 13:51:12 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


That's not what the website said. I actually downloaded
(a) the full version
(b) the full 2.4.2 patched kernel
(c) and the patch itself.

All have the same problem. The trick with dobule compile didn't work for
me.
I do run on Redhat 7.0.

Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



"frenzy@frenzy.org" <mcclellr@OIT.EDU>@tycho.nsa.gov on 03/24/2001 02:26:49
AM

Sent by:  owner-selinux@tycho.nsa.gov


To:
cc:   SELinux@tycho.nsa.gov
Subject:  Re: your mail



It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,

Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see
in the world." - Mahatma Gandhi
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt

On Fri, 23 Mar 2001, Hubertus Franke wrote:

just downloaded the SELinux for 2.4.

I did the ./tools/build-kernel  and get the following errors.


/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory


/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory

Looks like various files are missing in the distribution.
Any ideas ?


Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 26 Mar 2001 09:01:39 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: "frenzy@frenzy.org" <mcclellr@OIT.EDU>
cc: SELinux@tycho.nsa.gov
Subject: Re: your mail
In-Reply-To: <Pine.OSF.4.02.10103232325100.16137-100000@internet.oit.edu>
Message-ID: <Pine.SOL.3.95.1010326090014.1077C-100000@clipper.gw.tislabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


The kernel patch is based on the stock kernel sources from
www.kernel.org or its mirrors.  The current release provides
patches for kernel versions 2.2.18 and 2.4.2, although the
2.2-based patch is no longer being actively developed.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Fri, 23 Mar 2001, frenzy@frenzy.org wrote:

> It was my understanding that the kernel patch was only made for the
> supplied kernel that comes with RH6.1
> I could be completely wrong here however. The last one I tried it with was
> 2.2.17-14smp, which also failed to compile.
> Sincerely,
> 
> Randy McCleland-Bane
> http://www.frenzy.org -- Administrator
> MSN: drekbot@hotmail.com ICQ: 32276169
> EM: frenzy@frenzy.org,mcclellr@oit.edu
> "We must be the change we wish to see 
> in the world." - Mahatma Gandhi   
> PGP key: http://www.frenzy.org/frenzy/
> frenzy_at_frenzy.org.asc.txt
> 
> On Fri, 23 Mar 2001, Hubertus Franke wrote:
> 
> just downloaded the SELinux for 2.4.
> 
> I did the ./tools/build-kernel  and get the following errors.
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?
> 
> 
> Hubertus Franke
> Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 26 Mar 2001 08:57:44 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: Hubertus Franke <frankeh@us.ibm.com>
cc: SELinux@tycho.nsa.gov
Subject: Re: your mail
In-Reply-To: <OFC8827216.E70119F9-ON85256A18.007CF1F0@pok.ibm.com>
Message-ID: <Pine.SOL.3.95.1010326085159.1077B-100000@clipper.gw.tislabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


These header files should be automatically generated during
the build.  I just tried again with a clean copy of the release
on my RedHat 6.1 system, and it built without any problems.
Try expanding a clean copy of the release and building the
kernel by hand rather than using the build-kernel script, i.e.

tar xzf slinux-200103151617-release.tgz
cd slinux
ln -sf kernel-2.4 kernel
cd kernel
make xconfig or make menuconfig or make config
	(Configure the kernel appropriately.)
make dep
make 
make modules

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Fri, 23 Mar 2001, Hubertus Franke wrote:

> just downloaded the SELinux for 2.4.
> 
> I did the ./tools/build-kernel  and get the following errors.
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?
> 
> 
> Hubertus Franke
> Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from jazzswing.ncsc.mil (jazzswing.ncsc.mil [144.51.68.65])
	by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id IAA23202
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 08:36:37 -0500 (EST)
Received: from jazzswing.ncsc.mil (localhost [127.0.0.1])
	by jazzswing.ncsc.mil  with ESMTP id NAA22483
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 13:35:31 GMT
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by jazzswing.ncsc.mil  with ESMTP id NAA22479
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 13:35:30 GMT
Date: Wed, 27 Feb 2002 08:36:01 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: Metrix <metrix007@yahoo.com>
cc: <selinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <20020227113121.20222.qmail@web20604.mail.yahoo.com>
Message-ID: <Pine.GSO.4.33.0202270831060.12300-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On Wed, 27 Feb 2002, Metrix wrote:

> Hey people, just wanted to compliment you on the good
> job, I will actualy be using RSBAC as it suits my
> needs a bit better...
>
> My question is, what are the diferences of RSBAC
> [rsbac.org] and SELinux from a technical standpoint?

This has been previously discussed on the mailing list, and is also
summarized in the related work section of the Freenix '01 paper.  The
mailing list thread starts at
http://marc.theaimsgroup.com/?l=selinux&m=98618795624462&w=2 and the
Freenix '01 paper is available at
http://www.nsa.gov/selinux/freenix01-abs.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from jazzswing.ncsc.mil (jazzswing.ncsc.mil [144.51.68.65])
	by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id OAA25905
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 14:33:49 -0500 (EST)
Received: from jazzswing.ncsc.mil (localhost [127.0.0.1])
	by jazzswing.ncsc.mil  with ESMTP id TAA11697
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 19:32:42 GMT
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by jazzswing.ncsc.mil  with ESMTP id TAA11691
	for <selinux@tycho.nsa.gov>; Wed, 27 Feb 2002 19:32:41 GMT
Date: Wed, 27 Feb 2002 14:33:19 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: Metrix <metrix007@yahoo.com>
cc: <selinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <20020227190209.4638.qmail@web20604.mail.yahoo.com>
Message-ID: <Pine.GSO.4.33.0202271429230.12300-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On Wed, 27 Feb 2002, Metrix wrote:

> with selinux is it possible to say make a file or
> directory unable to be viewed, deleted or moved, or
> even altered, the ONLY operation allowed is
> appending....is this possible to implement with
> selinux?

You can certainly define a type, only grant append permission to it in
the policy configuration, and label a file with it.

> i am a bit unsure oh what MAC and such is, is there a
> guide somewhere that clearly explains it?

I'd suggest reading the papers available from
http://www.nsa.gov/selinux/docs.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 11 Mar 2002 09:07:45 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: Samarth  Sharma <samarth7880@rediffmail.com>
cc: <SELinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <20020310093940.30150.qmail@mailFA9.rediffmail.com>
Message-ID: <Pine.GSO.4.33.0203110836020.25401-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On 10 Mar 2002, Samarth  Sharma wrote:

> 1.On login i get the following message :
>   [ avc: denied {write} for pid=647 exe=/bin/login
>   path=/var/log/wtmp dev=03:07 ino=182350
>   scontext=system_u:system_r:local_login_t
>   tcontext=system_u:object_r:cron_log_t tclass=file ]
> what does this mean and how can i get around it.
>   i get similar messages while loading 'atd'.

This indicates that your /var/log/wtmp file has the wrong security context
(system_u:object_r:cron_log_t rather than system_u:object_r:wtmp_t).
Run 'make verbose' in your setfiles directory after logging into the
sysadm_r role and sysadm_t domain to ensure that all of your file security
contexts are set properly.  You should have done this originally as step
15 of the README after you first booted SELinux.  You still need to figure
out why this happened to prevent a recurrence.  Some possible
explanations:

1) You have a cron job set up to rotate wtmp (and other log files) using
something other than the SELinux-modified logrotate program.  The
SELinux-modified logrotate program ensures that rotated files retain the
security context of the original file.  If you are rotating wtmp in some
other way, then it will pick up the cron_log_t type by default, as noted
by Russell Coker.  In this case, you need to ensure that you preserve
security contexts on log files when you rotate them.

2) You've switched back-and-forth between running an ordinary Linux kernel
and the SELinux kernel, and the wtmp file was re-created (possibly
rotated) while running the ordinary Linux kernel.  In this case, it is
sufficient to run 'make verbose' in the setfiles directory to ensure that
the file security contexts are set properly.

> 2.Can u give me a specific example where SElinux is able to solve
> a security flaw in normal Linux

I'd suggest reading the FAQ (esp. question #2,
http://www.nsa.gov/selinux/faq.html#l2) and the two published papers
about SELinux from http://www.nsa.gov/selinux/docs.html.
The Inevitability of Failure background paper
(http://www.nsa.gov/selinux/inevit-abs.html) provides a good explanation
of why mandatory access controls are necessary in general.  Two simple
examples are confining malicious mobile code that exploits a flaw in your
web browser and confining an exploit of a flaw in apache, bind, sendmail,
or any other system service.

> 3.i tried loading the selinux kernel on an amd machine.
> however the machine keeps rebooting immediately after the lilo
> screen. Linux 7.1 (redhat) runs fine on this machine.

Make sure that you set up your Processor type and features correctly in
the kernel configuration before building the SELinux kernel.  You could
try using the default RedHat kernel configuration from the RedHat SRPM
with just a few alterations for the SELinux-related options.

> 4.how do u add a user to the system. i added a new user in the
> ../policy/users file with appropriate context and compiled the
> policy but security context for that user was not initialized.

You also need to update the /etc/security/default_context and
/etc/security/cron_context files to define default login and cron job
security contexts for the user.  These files will become obsolete pending
some ongoing work, so at some point, you will only need to update
policy/users.  Also, we've merged support for a generic unprivileged user
that will show up in the next public release, so you will no longer need
to update any of these files if the new user only requires unprivileged
access and does not need to be separated from other such users by the
policy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 15 Mar 2002 10:31:04 -0500 (EST)
From: Stephen Smalley <sds@tislabs.com>
To: =?iso-8859-1?Q?Vanuxem_gr=E9gory?= <gvanuxem@club-internet.fr>
cc: SELinux Mailing <SELinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <ADEEIKPBIEHIINPOFGAOIECBCBAA.gvanuxem@club-internet.fr>
Message-ID: <Pine.GSO.4.33.0203150952010.15480-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On Fri, 15 Mar 2002, [iso-8859-1] Vanuxem grégory wrote:

> I try to record the PSID directly in some attribute of inodes. Particularly
> in xfs.
> What do you think about that ?

This has come up previously on the mailing list, so you might want to
review the mailing list archives.  A brief review:

In the original SELinux kernel patch, we stored the PSID directly in a
spare field of the on-disk ext2 inode.  When SELinux was re-implemented to
use the LSM kernel patch, the persistent label mapping was changed to
maintain the inode-to-PSID mapping in a regular file rather than using a
field in the inode since LSM does not provide any low-level
filesystem-specific hooks.  That change allows SELinux to support other
filesystem types more easily, but has disadvantages in terms of
performance and consistency.

As support for extended attributes becomes mainstreamed, I'd like to see
SELinux enhanced to optionally use them for persistent labeling when they
are supported by the filesystem type.  This seems reasonable for XFS (but
see my earlier email regarding other issues with using XFS -
http://marc.theaimsgroup.com/?l=selinux&m=101300861319394&w=2).

Storing PSIDs via extended attributes is certainly one option.  Another
option would be to directly store file security contexts using extended
attributes, completely eliminating the separate persistent label mapping.
Regardless, you need to ensure that any changes you make don't prevent
SELinux from continuing to work with filesystems that do not support EAs.

> Another question, why the mapping inode->psid is always record in the file
> ...security/inode.
> For example, if I mount a file system that contained 50 differents types of
> files (context),the SECFILES keep all the mapping. Now I have just three
> types for the initialization, the root dir type, the fs type and the
> "file_t" type but the avc keep the precedent mapping (50 psids and
> contexts).

I'm not sure what you are asking.  The SELinux kernel module opens the
mapping files and does an initial load of the PSID-to-context mapping at
mount time.  The incore cache for the PSID-to-context mapping is for
performance.  The inode-to-PSID mapping would be too large to keep incore.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 24 Apr 2002 16:19:45 -0400 (EDT)
From: Stephen Smalley <sds@tislabs.com>
To: Debian User <rogelio@evoworks.evoserve.com>
cc: <SELinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <20020424182953.75A6C812DB@coffeesaur2.evoserve.com>
Message-ID: <Pine.GSO.4.33.0204241612160.18677-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On Thu, 25 Apr 2002, Debian User wrote:

> I just used the prel script. Now im working on the syntax. I have the two
> white papers with me. I think I need to define new types and domains.
> What would possibly be the criteria for the decision? A rule of thumb if
> i may say so.

First, read the selinux/README file, particularly the post-install
instructions (starting around step 18).  Make sure that you don't have any
system processes left in initrc_t, as mentioned in step 18.

Domains and types are security equivalence classes for processes and
objects, respectively.  In other words, all processes in the same domain
have the same permissions, and all objects with the same type (and class)
can be accessed in the same way.  You want to use a distinct domain or
type when you want to distinguish a process or an object from others in
the security policy.  Processes that have the same security properties can
be placed into the same domain.  Similarly for objects and types.

The new policy report should be helpful in getting you started, although
it still isn't at the level of a HOWTO, so I'm hoping that others will
start writing HOWTOs derived from it and expanding upon it.  I expect this
report to be released soon, but I'm not sure exactly when.  Some
people at Tresys Technology have started writing some white papers related
to the policy that you can find at http://www.tresys.com/selinux.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com














--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 24 Jul 2002 10:22:56 -0400 (EDT)
From: Stephen Smalley <sds@tislabs.com>
To: Richard Mayo <rmayo@caci.com>
cc: <SELinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <OF3775534F.EB0631B6-ON85256C00.004AAC59@hq.caci.com>
Message-ID: <Pine.GSO.4.33.0207241012160.17252-100000@raven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov


On Wed, 24 Jul 2002, Richard Mayo wrote:

> It's obvious to me how to configure my computer to boot only to SELinux,
> but how do I force the computer into Enforcing mode?

You need to specify enforcing=1 on the kernel command line, as noted in
selinux/README.  You can add an append="enforcing=1" line to the entry in
lilo.conf if using LILO or you can add enforcing=1 to the kernel line
in grub.conf if using GRUB.  If you want the kernel to always operate in
enforcing mode (i.e. never be able to toggle into permissive mode), you
can simply rebuild the kernel without the SELinux Development Module
option.  See step 20 of the README.

> Also, when a user logs on the system asks if he or she would like to switch
> user contexts.  Is there an easy way to suppress this?

You could change login.c to use get_default_user_sid rather than
get_user_sid if you want login to always use the default user SID.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from jazzswing.ncsc.mil (jazzswing.ncsc.mil [144.51.68.65])
	by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id JAA02750
	for <selinux@tycho.nsa.gov>; Thu, 8 Aug 2002 09:08:42 -0400 (EDT)
Received: from jazzswing.ncsc.mil (localhost [127.0.0.1])
	by jazzswing.ncsc.mil  with ESMTP id NAA23067
	for <selinux@tycho.nsa.gov>; Thu, 8 Aug 2002 13:07:46 GMT
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by jazzswing.ncsc.mil  with ESMTP id NAA23063
	for <selinux@tycho.nsa.gov>; Thu, 8 Aug 2002 13:07:45 GMT
Date: Thu, 8 Aug 2002 09:01:02 -0400 (EDT)
From: Wayne Salamon <wsalamon@tislabs.com>
To: Samarth  Sharma <samarth7880@rediffmail.com>
cc: <selinux@tycho.nsa.gov>
Subject: Re: your mail
In-Reply-To: <20020808112849.16449.qmail@webmail26.rediffmail.com>
Message-ID: <Pine.LNX.4.33.0208080850160.9323-100000@vox.gw.tislabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-selinux@tycho.nsa.gov
List-Id: selinux@tycho.nsa.gov

On 8 Aug 2002, Samarth  Sharma wrote:

> hi,
>   A security aware application like the sshd daemon acts as an
> object manager for all its related processes..is this correct?? or
> are object managers are a part of the kernel.
>   if sshd does act as an object manager who enforces the access
> decisions for the sshd daemon..
>   Also if the daemon does act as an object manager does it not
> involve incorporating policy logic in the manager therby violating
> the primary principle of Flask architecture..

  All object access by processes will be controlled by the SELinux
module.  Security aware applications can make use of extended system calls
provided with SELinux to control security IDs on objects, but only as far
as the policy allows. Therefore, there is no violation, or bypassing, of
the controls provided by the Flask architecture.

  The application can control labeling of objects, but not the enforcement
of the policy based on those labels.


-- 
Wayne Salamon
wsalamon@tislabs.com


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=6ps2=SU=vger.kernel.org=util-linux-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-8.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED,
	USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 7C4E9C10F0E
	for <util-linux@archiver.kernel.org>; Thu, 18 Apr 2019 09:09:41 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 5519E206B6
	for <util-linux@archiver.kernel.org>; Thu, 18 Apr 2019 09:09:41 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2388597AbfDRJJk (ORCPT <rfc822;util-linux@archiver.kernel.org>);
        Thu, 18 Apr 2019 05:09:40 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37420 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2388526AbfDRJJi (ORCPT <rfc822;util-linux@vger.kernel.org>);
        Thu, 18 Apr 2019 05:09:38 -0400
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by mx1.redhat.com (Postfix) with ESMTPS id F0225309EFFC;
        Thu, 18 Apr 2019 09:09:37 +0000 (UTC)
Received: from ws.net.home (unknown [10.40.205.130])
        by smtp.corp.redhat.com (Postfix) with ESMTPS id 3644F19C79;
        Thu, 18 Apr 2019 09:09:37 +0000 (UTC)
Date:   Thu, 18 Apr 2019 11:09:34 +0200
From:   Karel Zak <kzak@redhat.com>
To:     StuartIanNaylor <rolyantrauts@gmail.com>
Cc:     "util-linux@vger.kernel.org" <util-linux@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20190418090934.y7jp7ii4l72hhlgz@ws.net.home>
References: <92179e5f-d73e-974c-774e-09c2813434c0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <92179e5f-d73e-974c-774e-09c2813434c0@gmail.com>
User-Agent: NeoMutt/20180716-1108-40af05
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 18 Apr 2019 09:09:38 +0000 (UTC)
Sender: util-linux-owner@vger.kernel.org
Precedence: bulk
List-ID: <util-linux.vger.kernel.org>
X-Mailing-List: util-linux@vger.kernel.org

On Thu, Apr 18, 2019 at 08:59:54AM +0100, StuartIanNaylor wrote:
> A strange thing happens with zramctl as if all services where running the
> high order zram device of zramdrive is no longer visible after removing
> lower order devices.

Sounds like https://github.com/karelzak/util-linux/issues/521, fixed
in version 2.31

> Its Raspbian 4.14 with util-linux 2.29.2

The current upstream is 2.33.2 :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

From mboxrd@z Thu Jan  1 00:00:00 1970
From: thierry.reding@avionic-design.de (Thierry Reding)
Date: Fri, 2 Oct 2009 16:53:15 +0200
Subject: your mail
In-Reply-To: <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>
References: <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <20091002145315.GB25736@avionic-design.de>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

* Thierry Reding wrote:
> So it's been quite a while since I last posted this series and there have been
> a number of changes.
> 
> Support for T-Pid analog variants is dropped and will be handled in user-space
> instead. There hardware does not differ from the standard T-Pid. This gets rid 
> of some ugly platform-specific #ifdefs.
> 
> Front-panel controls are now handled in a separate driver, adx-keypad. That
> way backlight control can be moved to userspace.
> 
> This series also adds a watchdog driver that can be used on all Avionic Design
> Xanthos-based boards.

Russell,

with the watchdog and backlight drivers out of the way, would you like me to
get any of the other drivers (fb, keypad) in via seperate trees or can they go
in through the ARM tree?

Do the remaining patches need additional work or can I go ahead and submit
them to the patch system? Or do you prefer some other way to get them into
your tree?

Thierry

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 2 Jan 2010 12:06:19 +0000
Subject: your mail
In-Reply-To: <20091002145315.GB25736@avionic-design.de>
References: <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>
	<20091002145315.GB25736@avionic-design.de>
Message-ID: <20100102120618.GE2529@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Fri, Oct 02, 2009 at 04:53:15PM +0200, Thierry Reding wrote:
> * Thierry Reding wrote:
> > So it's been quite a while since I last posted this series and there have been
> > a number of changes.
> > 
> > Support for T-Pid analog variants is dropped and will be handled in user-space
> > instead. There hardware does not differ from the standard T-Pid. This gets rid 
> > of some ugly platform-specific #ifdefs.
> > 
> > Front-panel controls are now handled in a separate driver, adx-keypad. That
> > way backlight control can be moved to userspace.
> > 
> > This series also adds a watchdog driver that can be used on all Avionic Design
> > Xanthos-based boards.
> 
> Russell,
> 
> with the watchdog and backlight drivers out of the way, would you like me to
> get any of the other drivers (fb, keypad) in via seperate trees or can they go
> in through the ARM tree?

They should go in via the relevant driver trees.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ben-linux@fluff.org (Ben Dooks)
Date: Wed, 19 May 2010 03:24:08 +0100
Subject: your mail
In-Reply-To: <1274179129-14659-1-git-send-email-m.szyprowski@samsung.com>
References: <1274179129-14659-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <20100519022408.GN26401@trinity.fluff.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,

Hi, messages are supposed to have subjects... please supply one next
timne.
 
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
> 
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.

Ok, this seems to be a pretty good progression from one to the other.

I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.

Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
 
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
> 
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
>   code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
>   patches
> - some other minor cleanups (mainly c1xx to c100 renames)
> 
> This patch series includes:
> 
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: jamie@shareable.org (Jamie Lokier)
Date: Mon, 7 Jun 2010 23:10:47 +0100
Subject: your mail
In-Reply-To: <AANLkTikxfktI7Heocg8kaBFziT3CXMzRzr-RJcXSQhbG@mail.gmail.com>
References: <AANLkTikxfktI7Heocg8kaBFziT3CXMzRzr-RJcXSQhbG@mail.gmail.com>
Message-ID: <20100607221047.GA27304@shareable.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Dave Hylands wrote:
> I'm trying to understand what I need to be concerned about with SMP
> processors and sharing global data (in particular a dual Cortex-A9)
> 
> I'm familiar with spinlocks, but in this case I'm trying to work with
> some lockless data structures.
> 
> What I'm not sure is whether the following would work. Suppose I have
> a couple of 8-bit get/put indicies which are in adjacent memory
> locations (within the same 32-bit word).
> 
> If I have an ISR and a thread running on an SMP core, and the ISR is
> running on one core and the thread is running on a second core, if the
> ISR were to only write to the put pointer and the thread were only to
> write to the get pointer, does the cache maintain consistency? Or do
> the get and put pointers need to be in separate cache lines?
> 
> Another way of asking this: If both cores are writing to the same
> 32-bit word (but different bytes) do the writes collide?

I'm pretty sure any system compatible with pthreads has to be fine
with the variables being independent, because the bytes could be
variables protected by separate mutexes.

However, other questions for your lockless structures are whether
writes by one processor are seen in a reasonable or even bounded time
by reads on another processor (write buffering), and which barrier
instructions to use between the index accesses and accessing some
array they might indexing (only a problem for userspace, because the
kernel already provides barriers).

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
From: dhylands@gmail.com (Dave Hylands)
Date: Mon, 7 Jun 2010 15:44:16 -0700
Subject: your mail
In-Reply-To: <20100607221047.GA27304@shareable.org>
References: <AANLkTikxfktI7Heocg8kaBFziT3CXMzRzr-RJcXSQhbG@mail.gmail.com>
	<20100607221047.GA27304@shareable.org>
Message-ID: <AANLkTikA_eXw1fMwOtuPxLqlDdzz4IYJfsXkpuCSkOUw@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

HI Jamie,

On Mon, Jun 7, 2010 at 3:10 PM, Jamie Lokier wrote:
> Dave Hylands wrote:
[...]
>> Another way of asking this: If both cores are writing to the same
>> 32-bit word (but different bytes) do the writes collide?
>
> I'm pretty sure any system compatible with pthreads has to be fine
> with the variables being independent, because the bytes could be
> variables protected by separate mutexes.
>
> However, other questions for your lockless structures are whether
> writes by one processor are seen in a reasonable or even bounded time
> by reads on another processor (write buffering), and which barrier
> instructions to use between the index accesses and accessing some
> array they might indexing (only a problem for userspace, because the
> kernel already provides barriers).

After lots of reading - I think that the Snoop Control Unit takes care
of moving the cache lines from one core to the other when both cores
are trying to access data from the same cache line.

So it's not very efficient to have both cores accessing data from the
same cache line - but it seems that the integrity of the data should
be maintained (or at least this is my current understanding).

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

From mboxrd@z Thu Jan  1 00:00:00 1970
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 14 May 2011 05:32:24 +0200
Subject: your mail
In-Reply-To: <20110513193502.2BBAF40CD1@eskimo.mtv.corp.google.com>
References: <20110513193502.2BBAF40CD1@eskimo.mtv.corp.google.com>
Message-ID: <20110514033224.GA14136@game.jcrosoft.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 12:35 Fri 13 May     , Vadim Bendebury wrote:
> >From 8ed0ea5fcf5552ca3307611b685b4518794eca41 Mon Sep 17 00:00:00 2001
> From: Vadim Bendebury <vbendeb@chromium.org>
> Date: Wed, 11 May 2011 17:31:40 -0700
> Subject: [PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.
> 
> This is a cosmetic change, adding a '_thumb' prefix to the
> 'Hardware' line in /proc/cpuinfo. Tested as follows:
I do think is the right place or right way to do so

I think we need to create a sysfs entry to allow machine to more information

Best Regards,
J.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: will.deacon@arm.com (Will Deacon)
Date: Fri, 2 Dec 2011 16:11:13 +0000
Subject: your mail
In-Reply-To: <20111202160113.GA13965@mudshark.cambridge.arm.com>
References: <20111202160113.GA13965@mudshark.cambridge.arm.com>
Message-ID: <20111202161113.GL5540@mudshark.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Hmmm,

On Fri, Dec 02, 2011 at 04:01:13PM +0000, Will Deacon wrote:
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Not that there's a lot to ignore, but please ignore this empty mail. For
some reason, my box decided to tell the world nothing.

Sorry for the spam,

Will (thinks it's time for a reboot...)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: tony@atomide.com (Tony Lindgren)
Date: Fri, 22 Jun 2012 01:56:06 -0700
Subject: your mail
In-Reply-To: <alpine.DEB.2.00.1206211225360.10198@utopia.booyaka.com>
References: <alpine.DEB.2.00.1206211225360.10198@utopia.booyaka.com>
Message-ID: <20120622085605.GB12766@atomide.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
> 
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
> 
>   Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
> 
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
> 
>   Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
> 
> ----------------------------------------------------------------
> 
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
> 
> ----------------------------------------------------------------

Merging into cleanup-hwmod and merging into l-o master for testing.

Tony

From mboxrd@z Thu Jan  1 00:00:00 1970
From: mark.rutland@arm.com (Mark Rutland)
Date: Tue, 28 Oct 2014 14:19:07 +0000
Subject: your mail
In-Reply-To: <20141028141325.GE9796@leverpostej>
References: <20141028141325.GE9796@leverpostej>
Message-ID: <20141028141907.GG9796@leverpostej>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Oct 28, 2014 at 02:13:25PM +0000, Mark Rutland wrote:
> Bcc:
> Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
> Reply-To:
> In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>

Apologies for this, I appear to have accidentally inserted a newline and
confused my mail client. I'll resend this with that fixed.

Mark.

> 
> Hi Laura,
> 
> On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> > Add page protections for arm64 similar to those in arm.
> > This is for security reasons to prevent certain classes
> > of exploits. The current method:
> >
> > - Map all memory as either RWX or RW. We round to the nearest
> >   section to avoid creating page tables before everything is mapped
> > - Once everything is mapped, if either end of the RWX section should
> >   not be X, we split the PMD and remap as necessary
> > - When initmem is to be freed, we change the permissions back to
> >   RW (using stop machine if necessary to flush the TLB)
> > - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> >   read only.
> >
> > Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> > ---
> > v4: Combined the Kconfig options
> > ---
> >  arch/arm64/Kconfig.debug            |  23 +++
> >  arch/arm64/include/asm/cacheflush.h |   4 +
> >  arch/arm64/kernel/vmlinux.lds.S     |  17 ++
> >  arch/arm64/mm/init.c                |   1 +
> >  arch/arm64/mm/mm.h                  |   2 +
> >  arch/arm64/mm/mmu.c                 | 303 +++++++++++++++++++++++++++++++-----
> >  6 files changed, 314 insertions(+), 36 deletions(-)
> 
> With this patch applied to v3.18-rc2, my board to blows up at boot when
> using UEFI (without DEBUG_RODATA selected):
> 
> ---->8----
> EFI stub: Booting Linux Kernel...
> Initializing cgroup subsys cpu
> Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
> CPU: AArch64 Processor [410fd030] revision 0
> Detected VIPT I-cache on CPU0
> bootconsole [uart0] enabled
> efi: Getting EFI parameters from FDT:
> EFI v2.40 by ARM Juno EFI Oct  7 2014 15:05:42
> efi:  ACPI=0xfebdc000  ACPI 2.0=0xfebdc014
> cma: Reserved 16 MiB at fd800000
> BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
> Kernel panic - not syncing: BUG!
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
> Call trace:
> [<ffffffc000087ec8>] dump_backtrace+0x0/0x124
> [<ffffffc000087ffc>] show_stack+0x10/0x1c
> [<ffffffc0004ebd58>] dump_stack+0x74/0xb8
> [<ffffffc0004eb018>] panic+0xe0/0x220
> [<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
> [<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
> [<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
> [<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
> [<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
> [<ffffffc0006978a8>] setup_arch+0x408/0x5c0
> [<ffffffc00069566c>] start_kernel+0x94/0x3a0
> ---[ end Kernel panic - not syncing: BUG!
> ---->8----
> 
> I've not yet figured out precisely why. I haven't tried a !EFI boot
> because of the way my board is set up at the moment.
> 
> Mark.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave P Martin)
Date: Tue, 21 Apr 2015 11:46:36 +0100
Subject: your mail
In-Reply-To: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
Message-ID: <20150421104634.GA3996@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:13, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> a Thumb2 kernel. This ensures that these function are always called
> >> in the correct mode.
> >
> > I don't think this is necessary, in fact, I think this is positively
> > regression causing.
> >
> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> > As we have seen already from the kernel dumps from the V7M kernel, when
> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> > _odd_ number.
> >
> 
> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.

'| 1' is more logical, but can't be resolved at link time because
there's no relocation for this operation.  Hence '+ 1'.  This matters
for local cross-section references that can't be resolved at assembly
time.

> But looking at proc-v7.S again, the problem may just be the missing
> ENDPROC() declarations for a couple of the setup() functions, which
> explains why they are lacking the Thumb annotations.

Yes, if any are missing ENDPROC() then it should be added there.

Cheers
---Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
Date: Tue, 21 Apr 2015 12:50:02 +0200
Subject: your mail
In-Reply-To: <20150421104634.GA3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
Message-ID: <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> a Thumb2 kernel. This ensures that these function are always called
>> >> in the correct mode.
>> >
>> > I don't think this is necessary, in fact, I think this is positively
>> > regression causing.
>> >
>> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> > As we have seen already from the kernel dumps from the V7M kernel, when
>> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> > _odd_ number.
>> >
>>
>> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>
> '| 1' is more logical, but can't be resolved at link time because
> there's no relocation for this operation.  Hence '+ 1'.  This matters
> for local cross-section references that can't be resolved at assembly
> time.
>

OK, that makes sense. But it does appear that the local cross-section
references are working just fine, i.e., references from other sections
in the same .o have the thumb bit set correctly even without BSYM()

>> But looking at proc-v7.S again, the problem may just be the missing
>> ENDPROC() declarations for a couple of the setup() functions, which
>> explains why they are lacking the Thumb annotations.
>
> Yes, if any are missing ENDPROC() then it should be added there.
>

I am putting together a v2 with this instead of the BSYM() on the initfn


Cheers,
Ard.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave P Martin)
Date: Tue, 21 Apr 2015 12:10:43 +0100
Subject: your mail
In-Reply-To: <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
Message-ID: <20150421111042.GB3996@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> >> a Thumb2 kernel. This ensures that these function are always called
> >> >> in the correct mode.
> >> >
> >> > I don't think this is necessary, in fact, I think this is positively
> >> > regression causing.
> >> >
> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> >> > As we have seen already from the kernel dumps from the V7M kernel, when
> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> >> > _odd_ number.
> >> >
> >>
> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
> >
> > '| 1' is more logical, but can't be resolved at link time because
> > there's no relocation for this operation.  Hence '+ 1'.  This matters
> > for local cross-section references that can't be resolved at assembly
> > time.
> >
> 
> OK, that makes sense. But it does appear that the local cross-section
> references are working just fine, i.e., references from other sections
> in the same .o have the thumb bit set correctly even without BSYM()

For branch targets, the set of situations where BSYM must be used and
the set of situations where it must not be used are mutually exclusive:

 * If the assembler resolves the address and the address will be used as a
   branch target, BSYM() must be used.  This applies to non-cross-section
   references within in single object only.

 * If the linker resolves the address, BSYM() must not be used and the
   target label must be annotated with ENDPROC().  This applies to
   all cross-section or cross-object references.

For any address that won't be used as a branch target, BSYM() must not
be used.

Cross-section non-cross-object references where the target is missing
ENDPROC() and BSYM _is_ used will also work, but this should be avoided
-- it's an abuse really.


The reason for these rules is that the assembler doesn't do any Thumb
bit handling when taking the address of a local symbol, irrespective
of the symbol's type.  This can result in a screwup unless the assembler
can't resolve the address and must leave it as a relocation for the
linker to process, or if the correct annotation for the linker to do
the right fixup is missing.


I don't know the history of why this inconsistency exists between the
assembler and linker behaviour, but changing it would likely break
more stuff than it fixes now.

Maybe it would be a good idea to add a comment in asm/unified.h
explaining this, assuming (hopefully) that my explanation was right...

[...]

Cheers
---Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
Date: Tue, 21 Apr 2015 13:15:54 +0200
Subject: your mail
In-Reply-To: <20150421111042.GB3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
Message-ID: <CAKv+Gu_OUWKZ97PXdxmfA=mLTzV2Xti7rhmpuZtMAmd01=E01w@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 21 April 2015 at 13:10, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
>> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> >> a Thumb2 kernel. This ensures that these function are always called
>> >> >> in the correct mode.
>> >> >
>> >> > I don't think this is necessary, in fact, I think this is positively
>> >> > regression causing.
>> >> >
>> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> >> > As we have seen already from the kernel dumps from the V7M kernel, when
>> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> >> > _odd_ number.
>> >> >
>> >>
>> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>> >
>> > '| 1' is more logical, but can't be resolved at link time because
>> > there's no relocation for this operation.  Hence '+ 1'.  This matters
>> > for local cross-section references that can't be resolved at assembly
>> > time.
>> >
>>
>> OK, that makes sense. But it does appear that the local cross-section
>> references are working just fine, i.e., references from other sections
>> in the same .o have the thumb bit set correctly even without BSYM()
>
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
>
>  * If the assembler resolves the address and the address will be used as a
>    branch target, BSYM() must be used.  This applies to non-cross-section
>    references within in single object only.
>

Here, 'sym | 1' should work ...

>  * If the linker resolves the address, BSYM() must not be used and the
>    target label must be annotated with ENDPROC().  This applies to
>    all cross-section or cross-object references.
>
> For any address that won't be used as a branch target, BSYM() must not
> be used.
>
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.
>

... and for the other cases, we rely on the assembler to emit
relocations for the linker to process.

So in summary, defining BSYM() as 'sym + 1' rather than 'sym | 1' only
enables cases where BSYM() shouldn't be used in the first place. Or am
I missing something?

>
> The reason for these rules is that the assembler doesn't do any Thumb
> bit handling when taking the address of a local symbol, irrespective
> of the symbol's type.  This can result in a screwup unless the assembler
> can't resolve the address and must leave it as a relocation for the
> linker to process, or if the correct annotation for the linker to do
> the right fixup is missing.
>
>
> I don't know the history of why this inconsistency exists between the
> assembler and linker behaviour, but changing it would likely break
> more stuff than it fixes now.
>
> Maybe it would be a good idea to add a comment in asm/unified.h
> explaining this, assuming (hopefully) that my explanation was right...
>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 21 Apr 2015 12:24:20 +0100
Subject: your mail
In-Reply-To: <20150421111042.GB3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
Message-ID: <20150421112420.GV12732@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 12:10:43PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> > OK, that makes sense. But it does appear that the local cross-section
> > references are working just fine, i.e., references from other sections
> > in the same .o have the thumb bit set correctly even without BSYM()
> 
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
> 
>  * If the assembler resolves the address and the address will be used as a
>    branch target, BSYM() must be used.  This applies to non-cross-section
>    references within in single object only.
> 
>  * If the linker resolves the address, BSYM() must not be used and the
>    target label must be annotated with ENDPROC().  This applies to
>    all cross-section or cross-object references.

Yes, that agrees with the situation we have for the initfunc stuff.

> For any address that won't be used as a branch target, BSYM() must not
> be used.
> 
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.

We should probably create a badr macro to complement the adr pseudo-op
which incorporates the BSYM thing so make this clearer - and a comment
before it.  This is really the case where BSYM should be used.

We have one case in the kernel source which is probably buggy:

arch/arm/kvm/interrupts.S:      ldr     r2, =BSYM(panic)

and killing BSYM in favour of a badr macro would prevent this.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 21 Apr 2015 13:50:50 +0100
Subject: your mail
In-Reply-To: <20150421112420.GV12732@n2100.arm.linux.org.uk>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
Message-ID: <20150421125049.GW12732@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> We should probably create a badr macro to complement the adr pseudo-op
> which incorporates the BSYM thing so make this clearer - and a comment
> before it.  This is really the case where BSYM should be used.

Something like this.  Note that I've also removed the BSYM() usage in
the KVM code.

 arch/arm/boot/compressed/head.S          |  4 ++--
 arch/arm/common/mcpm_head.S              |  2 +-
 arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
 arch/arm/include/asm/entry-macro-multi.S |  4 ++--
 arch/arm/include/asm/unified.h           |  2 --
 arch/arm/kernel/entry-armv.S             | 12 ++++++------
 arch/arm/kernel/entry-common.S           |  6 +++---
 arch/arm/kernel/entry-ftrace.S           |  2 +-
 arch/arm/kernel/head-nommu.S             |  6 +++---
 arch/arm/kernel/head.S                   |  8 ++++----
 arch/arm/kernel/sleep.S                  |  2 +-
 arch/arm/kvm/interrupts.S                |  2 +-
 arch/arm/lib/call_with_stack.S           |  2 +-
 arch/arm/mm/proc-v7m.S                   |  2 +-
 14 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 2c45b5709fa4..06e983f59980 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -130,7 +130,7 @@ start:
 		.endr
    ARM(		mov	r0, r0		)
    ARM(		b	1f		)
- THUMB(		adr	r12, BSYM(1f)	)
+ THUMB(		badr	r12, 1f		)
  THUMB(		bx	r12		)
 
 		.word	_magic_sig	@ Magic numbers to help the loader
@@ -447,7 +447,7 @@ dtb_check_done:
 
 		bl	cache_clean_flush
 
-		adr	r0, BSYM(restart)
+		badr	r0, restart
 		add	r0, r0, r6
 		mov	pc, r0
 
diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
index e02db4b81a66..08b3bb9bc6a2 100644
--- a/arch/arm/common/mcpm_head.S
+++ b/arch/arm/common/mcpm_head.S
@@ -49,7 +49,7 @@
 ENTRY(mcpm_entry_point)
 
  ARM_BE8(setend        be)
- THUMB(	adr	r12, BSYM(1f)	)
+ THUMB(	badr	r12, 1f		)
  THUMB(	bx	r12		)
  THUMB(	.thumb			)
 1:
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 186270b3e194..4abe57279c66 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -178,6 +178,21 @@
 	.endm
 
 /*
+ * Assembly version of "adr rd, BSYM(sym)".  This should only be used to
+ * reference local symbols in the same assembly file which are to be
+ * resolved by the assembler.  Other usage is undefined.
+ */
+	.irp	c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
+	.macro	badr\c, rd, sym
+#ifdef CONFIG_THUMB2_KERNEL
+	adr\c	\rd, \sym + 1
+#else
+	adr\c	\rd, \sym
+#endif
+	.endm
+	.endr
+
+/*
  * Get current thread_info.
  */
 	.macro	get_thread_info, rd
@@ -326,7 +341,7 @@
 THUMB(	orr	\reg , \reg , #PSR_T_BIT	)
 	bne	1f
 	orr	\reg, \reg, #PSR_A_BIT
-	adr	lr, BSYM(2f)
+	badr	lr, 2f
 	msr	spsr_cxsf, \reg
 	__MSR_ELR_HYP(14)
 	__ERET
diff --git a/arch/arm/include/asm/entry-macro-multi.S b/arch/arm/include/asm/entry-macro-multi.S
index 469a2b30fa27..609184f522ee 100644
--- a/arch/arm/include/asm/entry-macro-multi.S
+++ b/arch/arm/include/asm/entry-macro-multi.S
@@ -10,7 +10,7 @@
 	@
 	@ routine called with r0 = irq number, r1 = struct pt_regs *
 	@
-	adrne	lr, BSYM(1b)
+	badrne	lr, 1b
 	bne	asm_do_IRQ
 
 #ifdef CONFIG_SMP
@@ -23,7 +23,7 @@
 	ALT_SMP(test_for_ipi r0, r2, r6, lr)
 	ALT_UP_B(9997f)
 	movne	r1, sp
-	adrne	lr, BSYM(1b)
+	badrne	lr, 1b
 	bne	do_IPI
 #endif
 9997:
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index 200f9a7cd623..a91ae499614c 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -45,7 +45,6 @@
 #define THUMB(x...)	x
 #ifdef __ASSEMBLY__
 #define W(instr)	instr.w
-#define BSYM(sym)	sym + 1
 #else
 #define WASM(instr)	#instr ".w"
 #endif
@@ -59,7 +58,6 @@
 #define THUMB(x...)
 #ifdef __ASSEMBLY__
 #define W(instr)	instr
-#define BSYM(sym)	sym
 #else
 #define WASM(instr)	#instr
 #endif
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 570306c49406..f8f7398c74c2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -40,7 +40,7 @@
 #ifdef CONFIG_MULTI_IRQ_HANDLER
 	ldr	r1, =handle_arch_irq
 	mov	r0, sp
-	adr	lr, BSYM(9997f)
+	badr	lr, 9997f
 	ldr	pc, [r1]
 #else
 	arch_irq_handler_default
@@ -273,7 +273,7 @@ __und_svc:
 	str	r4, [sp, #S_PC]
 	orr	r0, r9, r0, lsl #16
 #endif
-	adr	r9, BSYM(__und_svc_finish)
+	badr	r9, __und_svc_finish
 	mov	r2, r4
 	bl	call_fpe
 
@@ -469,7 +469,7 @@ __und_usr:
 	@ instruction, or the more conventional lr if we are to treat
 	@ this as a real undefined instruction
 	@
-	adr	r9, BSYM(ret_from_exception)
+	badr	r9, ret_from_exception
 
 	@ IRQs must be enabled before attempting to read the instruction from
 	@ user space since that could cause a page/translation fault if the
@@ -486,7 +486,7 @@ __und_usr:
 	@ r2 = PC value for the following instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the faulting instruction
 	@ lr = 32-bit undefined instruction function
-	adr	lr, BSYM(__und_usr_fault_32)
+	badr	lr, __und_usr_fault_32
 	b	call_fpe
 
 __und_usr_thumb:
@@ -522,7 +522,7 @@ ARM_BE8(rev16	r0, r0)				@ little endian instruction
 	add	r2, r2, #2			@ r2 is PC + 2, make it PC + 4
 	str	r2, [sp, #S_PC]			@ it's a 2x16bit instr, update
 	orr	r0, r0, r5, lsl #16
-	adr	lr, BSYM(__und_usr_fault_32)
+	badr	lr, __und_usr_fault_32
 	@ r0 = the two 16-bit Thumb instructions which caused the exception
 	@ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the first 16-bit Thumb instruction
@@ -716,7 +716,7 @@ __und_usr_fault_32:
 __und_usr_fault_16:
 	mov	r1, #2
 1:	mov	r0, sp
-	adr	lr, BSYM(ret_from_exception)
+	badr	lr, ret_from_exception
 	b	__und_fault
 ENDPROC(__und_usr_fault_32)
 ENDPROC(__und_usr_fault_16)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index f8ccc21fa032..6ab159384667 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -88,7 +88,7 @@ ENTRY(ret_from_fork)
 	bl	schedule_tail
 	cmp	r5, #0
 	movne	r0, r4
-	adrne	lr, BSYM(1f)
+	badrne	lr, 1f
 	retne	r5
 1:	get_thread_info tsk
 	b	ret_slow_syscall
@@ -196,7 +196,7 @@ local_restart:
 	bne	__sys_trace
 
 	cmp	scno, #NR_syscalls		@ check upper syscall limit
-	adr	lr, BSYM(ret_fast_syscall)	@ return address
+	badr	lr, ret_fast_syscall		@ return address
 	ldrcc	pc, [tbl, scno, lsl #2]		@ call sys_* routine
 
 	add	r1, sp, #S_OFF
@@ -231,7 +231,7 @@ __sys_trace:
 	add	r0, sp, #S_OFF
 	bl	syscall_trace_enter
 
-	adr	lr, BSYM(__sys_trace_return)	@ return address
+	badr	lr, __sys_trace_return		@ return address
 	mov	scno, r0			@ syscall number (possibly new)
 	add	r1, sp, #S_R0 + S_OFF		@ pointer to regs
 	cmp	scno, #NR_syscalls		@ check upper syscall limit
diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S
index fe57c73e70a4..c73c4030ca5d 100644
--- a/arch/arm/kernel/entry-ftrace.S
+++ b/arch/arm/kernel/entry-ftrace.S
@@ -87,7 +87,7 @@
 
 1: 	mcount_get_lr	r1			@ lr of instrumented func
 	mcount_adjust_addr	r0, lr		@ instrumented function
-	adr	lr, BSYM(2f)
+	badr	lr, 2f
 	mov	pc, r2
 2:	mcount_exit
 .endm
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 84da14b7cd04..c9660167ef1a 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -46,7 +46,7 @@ ENTRY(stext)
 	.arm
 ENTRY(stext)
 
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -79,7 +79,7 @@ ENTRY(stext)
 #endif
 	ldr	r13, =__mmap_switched		@ address to jump to after
 						@ initialising sctlr
-	adr	lr, BSYM(1f)			@ return (PIC) address
+	badr	lr, 1f				@ return (PIC) address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10
 	ret	r12
@@ -115,7 +115,7 @@ ENTRY(secondary_startup)
 	bl      __setup_mpu			@ Initialize the MPU
 #endif
 
-	adr	lr, BSYM(__after_proc_init)	@ return address
+	badr	lr, __after_proc_init		@ return address
 	mov	r13, r12			@ __secondary_switched address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 7304b4c44b52..1eecd57453be 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -80,7 +80,7 @@
 ENTRY(stext)
  ARM_BE8(setend	be )			@ ensure we are in BE8 mode
 
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -148,7 +148,7 @@ ENTRY(stext)
 	 */
 	ldr	r13, =__mmap_switched		@ address to jump to after
 						@ mmu has been enabled
-	adr	lr, BSYM(1f)			@ return (PIC) address
+	badr	lr, 1f				@ return (PIC) address
 #ifdef CONFIG_ARM_LPAE
 	mov	r5, #0				@ high TTBR0
 	mov	r8, r4, lsr #12			@ TTBR1 is swapper_pg_dir pfn
@@ -364,7 +364,7 @@ __turn_mmu_on_loc:
 	.text
 ENTRY(secondary_startup_arm)
 	.arm
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -400,7 +400,7 @@ ENTRY(secondary_startup)
 	add	r3, r7, lr
 	ldrd	r4, [r3, #0]			@ get secondary_data.pgdir
 	ldr	r8, [r3, #8]			@ get secondary_data.swapper_pg_dir
-	adr	lr, BSYM(__enable_mmu)		@ return address
+	badr	lr, __enable_mmu		@ return address
 	mov	r13, r12			@ __secondary_switched address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10			@ initialise processor
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 7d37bfc50830..76bb3128e135 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,7 +81,7 @@ ENTRY(__cpu_suspend)
 	mov	r1, r4			@ size of save block
 	add	r0, sp, #8		@ pointer to save block
 	bl	__cpu_suspend_save
-	adr	lr, BSYM(cpu_suspend_abort)
+	badr	lr, cpu_suspend_abort
 	ldmfd	sp!, {r0, pc}		@ call suspend fn
 ENDPROC(__cpu_suspend)
 	.ltorg
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 79caf79b304a..87847d2c5f99 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -309,7 +309,7 @@ ENTRY(kvm_call_hyp)
 THUMB(	orr	r2, r2, #PSR_T_BIT	)
 	msr	spsr_cxsf, r2
 	mrs	r1, ELR_hyp
-	ldr	r2, =BSYM(panic)
+	ldr	r2, =panic
 	msr	ELR_hyp, r2
 	ldr	r0, =\panic_str
 	clrex				@ Clear exclusive monitor
diff --git a/arch/arm/lib/call_with_stack.S b/arch/arm/lib/call_with_stack.S
index ed1a421813cb..bf3a40889205 100644
--- a/arch/arm/lib/call_with_stack.S
+++ b/arch/arm/lib/call_with_stack.S
@@ -35,7 +35,7 @@ ENTRY(call_with_stack)
 	mov	r2, r0
 	mov	r0, r1
 
-	adr	lr, BSYM(1f)
+	badr	lr, 1f
 	ret	r2
 
 1:	ldr	lr, [sp]
diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
index e08e1f2bab76..67d9209077c6 100644
--- a/arch/arm/mm/proc-v7m.S
+++ b/arch/arm/mm/proc-v7m.S
@@ -98,7 +98,7 @@ __v7m_setup:
 	str	r5, [r0, V7M_SCB_SHPR3]	@ set PendSV priority
 
 	@ SVC to run the kernel in this mode
-	adr	r1, BSYM(1f)
+	badr	r1, 1f
 	ldr	r5, [r12, #11 * 4]	@ read the SVC vector entry
 	str	r1, [r12, #11 * 4]	@ write the temporary SVC vector entry
 	mov	r6, lr			@ save LR

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
Date: Tue, 21 Apr 2015 15:10:42 +0200
Subject: your mail
In-Reply-To: <20150421125049.GW12732@n2100.arm.linux.org.uk>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 21 April 2015 at 14:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> We should probably create a badr macro to complement the adr pseudo-op
>> which incorporates the BSYM thing so make this clearer - and a comment
>> before it.  This is really the case where BSYM should be used.
>
> Something like this.  Note that I've also removed the BSYM() usage in
> the KVM code.
>

Yes, that is much better. It is a pity that we still can't use '| 1'
but the fact that you are forced to use 'adr' now probably mostly
eliminates the risk regarding that.

I did notice that are are 4 or 5 instances (commented inline) of an
ARM to thumb mode switch which can just as easily be implemented as
'blx 1f' instead of using this badr macro (whose use we want to
discourage, I assume, since the address arithmetic is still slightly
dodgy). Do you think we should do something about that as well?

>  arch/arm/boot/compressed/head.S          |  4 ++--
>  arch/arm/common/mcpm_head.S              |  2 +-
>  arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
>  arch/arm/include/asm/entry-macro-multi.S |  4 ++--
>  arch/arm/include/asm/unified.h           |  2 --
>  arch/arm/kernel/entry-armv.S             | 12 ++++++------
>  arch/arm/kernel/entry-common.S           |  6 +++---
>  arch/arm/kernel/entry-ftrace.S           |  2 +-
>  arch/arm/kernel/head-nommu.S             |  6 +++---
>  arch/arm/kernel/head.S                   |  8 ++++----
>  arch/arm/kernel/sleep.S                  |  2 +-
>  arch/arm/kvm/interrupts.S                |  2 +-
>  arch/arm/lib/call_with_stack.S           |  2 +-
>  arch/arm/mm/proc-v7m.S                   |  2 +-
>  14 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
>                 .endr
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
> - THUMB(                adr     r12, BSYM(1f)   )
> + THUMB(                badr    r12, 1f         )
>   THUMB(                bx      r12             )
>

blx 1f

>                 .word   _magic_sig      @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
>
>                 bl      cache_clean_flush
>
> -               adr     r0, BSYM(restart)
> +               badr    r0, restart
>                 add     r0, r0, r6
>                 mov     pc, r0
>
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
>  ENTRY(mcpm_entry_point)
>
>   ARM_BE8(setend        be)
> - THUMB(        adr     r12, BSYM(1f)   )
> + THUMB(        badr    r12, 1f         )
>   THUMB(        bx      r12             )
>   THUMB(        .thumb                  )
>  1:

likewise

> [...]
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 84da14b7cd04..c9660167ef1a 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -46,7 +46,7 @@ ENTRY(stext)
>         .arm
>  ENTRY(stext)
>
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is always entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

> @@ -79,7 +79,7 @@ ENTRY(stext)
>  #endif
>         ldr     r13, =__mmap_switched           @ address to jump to after
>                                                 @ initialising sctlr
> -       adr     lr, BSYM(1f)                    @ return (PIC) address
> +       badr    lr, 1f                          @ return (PIC) address
>         ldr     r12, [r10, #PROCINFO_INITFUNC]
>         add     r12, r12, r10
>         ret     r12
> @@ -115,7 +115,7 @@ ENTRY(secondary_startup)
>         bl      __setup_mpu                     @ Initialize the MPU
>  #endif
>
> -       adr     lr, BSYM(__after_proc_init)     @ return address
> +       badr    lr, __after_proc_init           @ return address
>         mov     r13, r12                        @ __secondary_switched address
>         ldr     r12, [r10, #PROCINFO_INITFUNC]
>         add     r12, r12, r10
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 7304b4c44b52..1eecd57453be 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -80,7 +80,7 @@
>  ENTRY(stext)
>   ARM_BE8(setend        be )                    @ ensure we are in BE8 mode
>
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is always entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

> @@ -148,7 +148,7 @@ ENTRY(stext)
>          */
>         ldr     r13, =__mmap_switched           @ address to jump to after
>                                                 @ mmu has been enabled
> -       adr     lr, BSYM(1f)                    @ return (PIC) address
> +       badr    lr, 1f                          @ return (PIC) address
>  #ifdef CONFIG_ARM_LPAE
>         mov     r5, #0                          @ high TTBR0
>         mov     r8, r4, lsr #12                 @ TTBR1 is swapper_pg_dir pfn
> @@ -364,7 +364,7 @@ __turn_mmu_on_loc:
>         .text
>  ENTRY(secondary_startup_arm)
>         .arm
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

-- 
Ard.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave P Martin)
Date: Tue, 21 Apr 2015 14:18:03 +0100
Subject: your mail
In-Reply-To: <20150421125049.GW12732@n2100.arm.linux.org.uk>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
Message-ID: <20150421131801.GD3996@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > We should probably create a badr macro to complement the adr pseudo-op
> > which incorporates the BSYM thing so make this clearer - and a comment
> > before it.  This is really the case where BSYM should be used.
> 
> Something like this.  Note that I've also removed the BSYM() usage in
> the KVM code.

Nice.  Wrapping this around adr will make the assembler check that it's
not a cross-section reference too.

>  arch/arm/boot/compressed/head.S          |  4 ++--
>  arch/arm/common/mcpm_head.S              |  2 +-
>  arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
>  arch/arm/include/asm/entry-macro-multi.S |  4 ++--
>  arch/arm/include/asm/unified.h           |  2 --
>  arch/arm/kernel/entry-armv.S             | 12 ++++++------
>  arch/arm/kernel/entry-common.S           |  6 +++---
>  arch/arm/kernel/entry-ftrace.S           |  2 +-
>  arch/arm/kernel/head-nommu.S             |  6 +++---
>  arch/arm/kernel/head.S                   |  8 ++++----
>  arch/arm/kernel/sleep.S                  |  2 +-
>  arch/arm/kvm/interrupts.S                |  2 +-
>  arch/arm/lib/call_with_stack.S           |  2 +-
>  arch/arm/mm/proc-v7m.S                   |  2 +-
>  14 files changed, 42 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
>                 .endr
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
> - THUMB(                adr     r12, BSYM(1f)   )
> + THUMB(                badr    r12, 1f         )
>   THUMB(                bx      r12             )
> 
>                 .word   _magic_sig      @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
> 
>                 bl      cache_clean_flush
> 
> -               adr     r0, BSYM(restart)
> +               badr    r0, restart
>                 add     r0, r0, r6
>                 mov     pc, r0
> 
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
>  ENTRY(mcpm_entry_point)
> 
>   ARM_BE8(setend        be)
> - THUMB(        adr     r12, BSYM(1f)   )
> + THUMB(        badr    r12, 1f         )
>   THUMB(        bx      r12             )
>   THUMB(        .thumb                  )
>  1:
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 186270b3e194..4abe57279c66 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -178,6 +178,21 @@
>         .endm
> 
>  /*
> + * Assembly version of "adr rd, BSYM(sym)".  This should only be used to
> + * reference local symbols in the same assembly file which are to be
> + * resolved by the assembler.  Other usage is undefined.

BSYM() is gone, so this comment shouldn't refer to it...

> + */
> +       .irp    c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo

This wrap-macro-with-cc idiom could be factored, but it may not be worth
it just yet.

[...]

Cheers
---Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave P Martin)
Date: Tue, 21 Apr 2015 14:21:46 +0100
Subject: your mail
In-Reply-To: <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
Message-ID: <20150421132139.GE3996@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 14:50, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> We should probably create a badr macro to complement the adr pseudo-op
> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> before it.  This is really the case where BSYM should be used.
> >
> > Something like this.  Note that I've also removed the BSYM() usage in
> > the KVM code.
> >
> 
> Yes, that is much better. It is a pity that we still can't use '| 1'
> but the fact that you are forced to use 'adr' now probably mostly
> eliminates the risk regarding that.
> 
> I did notice that are are 4 or 5 instances (commented inline) of an
> ARM to thumb mode switch which can just as easily be implemented as
> 'blx 1f' instead of using this badr macro (whose use we want to
> discourage, I assume, since the address arithmetic is still slightly
> dodgy). Do you think we should do something about that as well?

Err, probably.  That just looks like an oversight -- I think I'm
responsible for at least some of those.

There's no good reason not to replace adr+BSYM+bx.

For switches from ARM, this could be replaced with bx <label> which
should work just fine.  There shouldn't be any instances of this from
Thumb, because switching instruction set is the whole point here.

(Thumb doesn't have bx <label>, but blx <label> is available at the cost
of clobbering lr).

Cheers
---Dave

[...]

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
Date: Tue, 21 Apr 2015 15:28:14 +0200
Subject: your mail
In-Reply-To: <20150421132139.GE3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
 <20150421132139.GE3996@e103592.cambridge.arm.com>
Message-ID: <CAKv+Gu8Wd5MX0Ly5Okx57MpUeGpkNGHhqFCSqxy_HWFbsgtnOQ@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 14:50, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> >> We should probably create a badr macro to complement the adr pseudo-op
>> >> which incorporates the BSYM thing so make this clearer - and a comment
>> >> before it.  This is really the case where BSYM should be used.
>> >
>> > Something like this.  Note that I've also removed the BSYM() usage in
>> > the KVM code.
>> >
>>
>> Yes, that is much better. It is a pity that we still can't use '| 1'
>> but the fact that you are forced to use 'adr' now probably mostly
>> eliminates the risk regarding that.
>>
>> I did notice that are are 4 or 5 instances (commented inline) of an
>> ARM to thumb mode switch which can just as easily be implemented as
>> 'blx 1f' instead of using this badr macro (whose use we want to
>> discourage, I assume, since the address arithmetic is still slightly
>> dodgy). Do you think we should do something about that as well?
>
> Err, probably.  That just looks like an oversight -- I think I'm
> responsible for at least some of those.
>
> There's no good reason not to replace adr+BSYM+bx.
>
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine.  There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.
>
> (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> of clobbering lr).
>

It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does
the job nicely as well.
And as you say, there are no instances of Thumb->ARM mode switches.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 21 Apr 2015 14:55:52 +0100
Subject: your mail
In-Reply-To: <20150421131801.GD3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <20150421131801.GD3996@e103592.cambridge.arm.com>
Message-ID: <20150421135552.GX12732@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > > We should probably create a badr macro to complement the adr pseudo-op
> > > which incorporates the BSYM thing so make this clearer - and a comment
> > > before it.  This is really the case where BSYM should be used.
> > 
> > Something like this.  Note that I've also removed the BSYM() usage in
> > the KVM code.
> 
> Nice.  Wrapping this around adr will make the assembler check that it's
> not a cross-section reference too.

While looking at this, I've become very upset with our toolchain's
abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
for using blx:

00000000 <secondary_startup_arm>:
   0:   fafffffe        blx     4 <secondary_startup>

00000004 <secondary_startup>:
   4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
   8:   f3ef 8900       mrs     r9, CPSR
   c:   f089 091a       eor.w   r9, r9, #26
  10:   f019 0f1f       tst.w   r9, #31

That's fine, but now if we look at the .head.text section (I also added
an ENTRY(start) to try and solve this):

00000000 <stext>:
   0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff

00000004 <start>:
   4:   fffef7ff        .word   0xfffef7ff
   8:   f3ef 8900       mrs     r9, CPSR
   c:   091af089        .word   0x091af089
  10:   f019 0f1f       tst.w   r9, #31
  14:   091ff029        .word   0x091ff029
  18:   09d3f049        .word   0x09d3f049
  1c:   f049 0920       orr.w   r9, r9, #32
  20:   f449d109        .word   0xf449d109
  24:   f20f7980        .word   0xf20f7980
  28:   0e13            lsrs    r3, r2, #24
  2a:   f399            .short  0xf399
  2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
  2e:   f38e            .short  0xf38e
  30:   f3de8e30        .word   0xf3de8e30
  34:   8f00            .short  0x8f00
  36:   f389 8100       msr     CPSR_c, r9

readelf for this shows for section 5:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
...
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     4: 00000000     0 SECTION LOCAL  DEFAULT    5
     5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
     6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
     7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
     8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
...
    65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
    66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start

One has to wonder about the toolchain when the stupid $[adt] hack seems
to be going soooo wrong.

I think I'm going to stop working on this until we have a toolchain
which behaves sensibly... when you can't get the damned thing to
disassemble for confirmation purposes, its best to leave the damned
code alone.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 21 Apr 2015 15:05:43 +0100
Subject: your mail
In-Reply-To: <20150421132139.GE3996@e103592.cambridge.arm.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
 <20150421132139.GE3996@e103592.cambridge.arm.com>
Message-ID: <20150421140543.GY12732@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 02:21:46PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> > Yes, that is much better. It is a pity that we still can't use '| 1'
> > but the fact that you are forced to use 'adr' now probably mostly
> > eliminates the risk regarding that.
> > 
> > I did notice that are are 4 or 5 instances (commented inline) of an
> > ARM to thumb mode switch which can just as easily be implemented as
> > 'blx 1f' instead of using this badr macro (whose use we want to
> > discourage, I assume, since the address arithmetic is still slightly
> > dodgy). Do you think we should do something about that as well?
> 
> Err, probably.  That just looks like an oversight -- I think I'm
> responsible for at least some of those.
> 
> There's no good reason not to replace adr+BSYM+bx.
> 
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine.  There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.

Where do you get this bx <label> from?  It doesn't seem to be in
DDI0406C.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
Date: Tue, 21 Apr 2015 16:06:02 +0200
Subject: your mail
In-Reply-To: <20150421135552.GX12732@n2100.arm.linux.org.uk>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <20150421131801.GD3996@e103592.cambridge.arm.com>
 <20150421135552.GX12732@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu_KsgBau8f8ZmUpBZmD4chmRsD2126LcN5qeNEwcJH+oQ@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 21 April 2015 at 15:55, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
>> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> > > We should probably create a badr macro to complement the adr pseudo-op
>> > > which incorporates the BSYM thing so make this clearer - and a comment
>> > > before it.  This is really the case where BSYM should be used.
>> >
>> > Something like this.  Note that I've also removed the BSYM() usage in
>> > the KVM code.
>>
>> Nice.  Wrapping this around adr will make the assembler check that it's
>> not a cross-section reference too.
>
> While looking at this, I've become very upset with our toolchain's
> abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
> for using blx:
>
> 00000000 <secondary_startup_arm>:
>    0:   fafffffe        blx     4 <secondary_startup>
>
> 00000004 <secondary_startup>:
>    4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
>    8:   f3ef 8900       mrs     r9, CPSR
>    c:   f089 091a       eor.w   r9, r9, #26
>   10:   f019 0f1f       tst.w   r9, #31
>
> That's fine, but now if we look at the .head.text section (I also added
> an ENTRY(start) to try and solve this):
>
> 00000000 <stext>:
>    0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff
>
> 00000004 <start>:
>    4:   fffef7ff        .word   0xfffef7ff
>    8:   f3ef 8900       mrs     r9, CPSR
>    c:   091af089        .word   0x091af089
>   10:   f019 0f1f       tst.w   r9, #31
>   14:   091ff029        .word   0x091ff029
>   18:   09d3f049        .word   0x09d3f049
>   1c:   f049 0920       orr.w   r9, r9, #32
>   20:   f449d109        .word   0xf449d109
>   24:   f20f7980        .word   0xf20f7980
>   28:   0e13            lsrs    r3, r2, #24
>   2a:   f399            .short  0xf399
>   2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
>   2e:   f38e            .short  0xf38e
>   30:   f3de8e30        .word   0xf3de8e30
>   34:   8f00            .short  0x8f00
>   36:   f389 8100       msr     CPSR_c, r9
>
> readelf for this shows for section 5:
>
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
> ...
>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>      4: 00000000     0 SECTION LOCAL  DEFAULT    5
>      5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
>      6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
>      7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
>      8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
> ...
>     65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
>     66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start
>
> One has to wonder about the toolchain when the stupid $[adt] hack seems
> to be going soooo wrong.
>
> I think I'm going to stop working on this until we have a toolchain
> which behaves sensibly... when you can't get the damned thing to
> disassemble for confirmation purposes, its best to leave the damned
> code alone.
>

It indeed seems to be objdump that is failing, but the code itself
looks fine to me.  For the record, binutils v2.23.52 works fine

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave Martin)
Date: Tue, 21 Apr 2015 16:51:01 +0100
Subject: your mail
In-Reply-To: <CAKv+Gu8Wd5MX0Ly5Okx57MpUeGpkNGHhqFCSqxy_HWFbsgtnOQ@mail.gmail.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <CAKv+Gu9TkvEGLz-8K_F3jbvourWw8R-XScGSPagxbaakRXZKpg@mail.gmail.com>
 <20150421132139.GE3996@e103592.cambridge.arm.com>
 <CAKv+Gu8Wd5MX0Ly5Okx57MpUeGpkNGHhqFCSqxy_HWFbsgtnOQ@mail.gmail.com>
Message-ID: <20150421135720.GA20723@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 03:28:14PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 14:50, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> >> We should probably create a badr macro to complement the adr pseudo-op
> >> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> >> before it.  This is really the case where BSYM should be used.
> >> >
> >> > Something like this.  Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >> >
> >>
> >> Yes, that is much better. It is a pity that we still can't use '| 1'
> >> but the fact that you are forced to use 'adr' now probably mostly
> >> eliminates the risk regarding that.
> >>
> >> I did notice that are are 4 or 5 instances (commented inline) of an
> >> ARM to thumb mode switch which can just as easily be implemented as
> >> 'blx 1f' instead of using this badr macro (whose use we want to
> >> discourage, I assume, since the address arithmetic is still slightly
> >> dodgy). Do you think we should do something about that as well?
> >
> > Err, probably.  That just looks like an oversight -- I think I'm
> > responsible for at least some of those.
> >
> > There's no good reason not to replace adr+BSYM+bx.
> >
> > For switches from ARM, this could be replaced with bx <label> which
> > should work just fine.  There shouldn't be any instances of this from
> > Thumb, because switching instruction set is the whole point here.
> >
> > (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> > of clobbering lr).
> >
> 
> It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does

Duh, I'm getting myself confused.  Yes, both have blx <label> but not
bx <label>.

Note that blx may result in suboptimal branch prediction because it
looks like a function call.  But these aren't hot paths, so I doubt
it matters.

> the job nicely as well.

Bit icky though...

Cheers
---Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave.Martin@arm.com (Dave Martin)
Date: Tue, 21 Apr 2015 18:03:55 +0100
Subject: your mail
In-Reply-To: <CAKv+Gu_KsgBau8f8ZmUpBZmD4chmRsD2126LcN5qeNEwcJH+oQ@mail.gmail.com>
References: <CAKv+Gu9u73+YKn+aR1vk+1eNF_voC71THWRQS96jyAt4HB3BQw@mail.gmail.com>
 <20150421104634.GA3996@e103592.cambridge.arm.com>
 <CAKv+Gu-3iM2+TvAgfV91FzfgAQuZhr=beeJ8RWmmGjTChbUrtQ@mail.gmail.com>
 <20150421111042.GB3996@e103592.cambridge.arm.com>
 <20150421112420.GV12732@n2100.arm.linux.org.uk>
 <20150421125049.GW12732@n2100.arm.linux.org.uk>
 <20150421131801.GD3996@e103592.cambridge.arm.com>
 <20150421135552.GX12732@n2100.arm.linux.org.uk>
 <CAKv+Gu_KsgBau8f8ZmUpBZmD4chmRsD2126LcN5qeNEwcJH+oQ@mail.gmail.com>
Message-ID: <20150421170355.GB20723@e103592.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Apr 21, 2015 at 04:06:02PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:55, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> >> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> > > We should probably create a badr macro to complement the adr pseudo-op
> >> > > which incorporates the BSYM thing so make this clearer - and a comment
> >> > > before it.  This is really the case where BSYM should be used.
> >> >
> >> > Something like this.  Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >>
> >> Nice.  Wrapping this around adr will make the assembler check that it's
> >> not a cross-section reference too.
> >
> > While looking at this, I've become very upset with our toolchain's
> > abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
> > for using blx:
> >
> > 00000000 <secondary_startup_arm>:
> >    0:   fafffffe        blx     4 <secondary_startup>
> >
> > 00000004 <secondary_startup>:
> >    4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
> >    8:   f3ef 8900       mrs     r9, CPSR
> >    c:   f089 091a       eor.w   r9, r9, #26
> >   10:   f019 0f1f       tst.w   r9, #31
> >
> > That's fine, but now if we look at the .head.text section (I also added
> > an ENTRY(start) to try and solve this):
> >
> > 00000000 <stext>:
> >    0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff
> >
> > 00000004 <start>:
> >    4:   fffef7ff        .word   0xfffef7ff
> >    8:   f3ef 8900       mrs     r9, CPSR
> >    c:   091af089        .word   0x091af089
> >   10:   f019 0f1f       tst.w   r9, #31
> >   14:   091ff029        .word   0x091ff029
> >   18:   09d3f049        .word   0x09d3f049
> >   1c:   f049 0920       orr.w   r9, r9, #32
> >   20:   f449d109        .word   0xf449d109
> >   24:   f20f7980        .word   0xf20f7980
> >   28:   0e13            lsrs    r3, r2, #24
> >   2a:   f399            .short  0xf399
> >   2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
> >   2e:   f38e            .short  0xf38e
> >   30:   f3de8e30        .word   0xf3de8e30
> >   34:   8f00            .short  0x8f00
> >   36:   f389 8100       msr     CPSR_c, r9
> >
> > readelf for this shows for section 5:
> >
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
> > ...
> >    Num:    Value  Size Type    Bind   Vis      Ndx Name
> >      4: 00000000     0 SECTION LOCAL  DEFAULT    5
> >      5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
> >      6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
> >      7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
> >      8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
> > ...
> >     65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
> >     66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start
> >
> > One has to wonder about the toolchain when the stupid $[adt] hack seems
> > to be going soooo wrong.
> >
> > I think I'm going to stop working on this until we have a toolchain
> > which behaves sensibly... when you can't get the damned thing to
> > disassemble for confirmation purposes, its best to leave the damned
> > code alone.
> >
> 
> It indeed seems to be objdump that is failing, but the code itself
> looks fine to me.  For the record, binutils v2.23.52 works fine

I've come across weird disassembly issues like this in the past.
The objdump code is something of a fragmented mess (shock, horror),
but I think there were fixes in the pipeline for some issues of this
sort.

If it is possible to manually check most or all of the cases of
badr, that might be sufficient -- this only gets used in a few,
specific places.

Objdump doesn't inspire much confidence though :(

Cheers
---Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129314AbQLKPnR>; Mon, 11 Dec 2000 10:43:17 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129778AbQLKPnH>; Mon, 11 Dec 2000 10:43:07 -0500
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:38413 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S129314AbQLKPmu>; Mon, 11 Dec 2000 10:42:50 -0500
Subject: Re: your mail
To: Heiko.Carstens@de.ibm.com
Date: Mon, 11 Dec 2000 15:14:35 +0000 (GMT)
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <C12569B2.004D1644.00@d12mta01.de.ibm.com> from "Heiko.Carstens@de.ibm.com" at Dec 11, 2000 03:01:55 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E145Uf0-00081R-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> sigp. To synchronize n CPUs one can create n kernel threads and give
> them a high priority to make sure they will be executed soon (e.g. by
> setting p->policy to SCHED_RR and p->rt_priority to a very high
> value). As soon as all CPUs are in synchronized state (with
> interrupts disabled) the new CPU can be started. But before this can
> be done there are some other things left to do:

You dont IMHO need to use such a large hammer. We already do similar sequences
for tlb invalidation on X86 for example. You can broadcast an interprocessor
interrupt and have the other processors set a flag each. You spin until they
are all captured, then when you clear the flag they all continue. You just
need to watch two processors doing it at the same time 8)

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S130255AbRAKEJY>; Wed, 10 Jan 2001 23:09:24 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S131182AbRAKEJO>; Wed, 10 Jan 2001 23:09:14 -0500
Received: from marine.sonic.net ([208.201.224.37]:52824 "HELO marine.sonic.net")
	by vger.kernel.org with SMTP id <S130255AbRAKEJA>;
	Wed, 10 Jan 2001 23:09:00 -0500
X-envelope-info: <dhinds@sonic.net>
Message-ID: <20010110200841.B12593@sonic.net>
Date: Wed, 10 Jan 2001 20:08:41 -0800
From: David Hinds <dhinds@sonic.net>
To: Thiago Rondon <maluco@mileniumnet.com.br>, dahinds@users.sourceforge.net
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
        Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.21.0101101623150.4170-100000@freak.mileniumnet.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93i
In-Reply-To: <Pine.LNX.4.21.0101101623150.4170-100000@freak.mileniumnet.com.br>; from Thiago Rondon on Wed, Jan 10, 2001 at 04:24:21PM -0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 10, 2001 at 04:24:21PM -0200, Thiago Rondon wrote:
> 
> Check kmalloc().
> 
> -Thiago Rondon
> 
> --- linux-2.4.0-ac5/drivers/pcmcia/ds.c	Sat Sep  2 04:13:49 2000
> +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.c	Wed Jan 10 16:20:53 2001
> @@ -414,6 +414,8 @@
>      /* Add binding to list for this socket */
>      driver->use_count++;
>      b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL);
> +    if (!b) 
> +      return -ENOMEM;    
>      b->driver = driver;
>      b->function = bind_info->function;
>      b->instance = NULL;
> 

As with the other kmalloc patch, this is also broken; things have been
done that need to be un-done, and you can't just exit the function
here.  I'll come up with a better fix.

-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S132001AbRASOij>; Fri, 19 Jan 2001 09:38:39 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S132147AbRASOi3>; Fri, 19 Jan 2001 09:38:29 -0500
Received: from anchor-post-33.mail.demon.net ([194.217.242.91]:37640 "EHLO
	anchor-post-33.mail.demon.net") by vger.kernel.org with ESMTP
	id <S132001AbRASOiS>; Fri, 19 Jan 2001 09:38:18 -0500
Date: Fri, 19 Jan 2001 14:37:42 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
To: RobertKaiser <rob@sysgo.de>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <01011914400800.01594@rob>
Message-ID: <Pine.LNX.4.21.0101191436190.2810-100000@sorbus.navaho>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 19 Jan 2001, RobertKaiser wrote:

> On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> > hardware?  It doesn't even seem to start (I get nothing on the screen from
> >t he kernel, it just sits there and does nothing). :(
> 
> What processor does it use ? (386 or 486 perchance?)

AMD K6 (so 586) - I was trying the i386 version of the kernel on it
though, if that's going to be a problem, I can try the 586 version...

-- 

- Steve Hill
System Administrator         Email: steve@navaho.co.uk
Navaho Technologies Ltd.       Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129764AbRCGAkn>; Tue, 6 Mar 2001 19:40:43 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129771AbRCGAkd>; Tue, 6 Mar 2001 19:40:33 -0500
Received: from mail.valinux.com ([198.186.202.175]:32261 "EHLO
	mail.valinux.com") by vger.kernel.org with ESMTP id <S129764AbRCGAk0>;
	Tue, 6 Mar 2001 19:40:26 -0500
Date: Tue, 6 Mar 2001 16:40:00 -0800
To: Ying Chen <yingchenb@hotmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010306164000.A28219@valinux.com>
In-Reply-To: <F41oVQAiEGKROptzzpY000014a6@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F41oVQAiEGKROptzzpY000014a6@hotmail.com>; from yingchenb@hotmail.com on Tue, Mar 06, 2001 at 03:55:55PM -0800
From: Don Dugger <n0ano@valinux.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ying-

I'm a little confused here.  It's very hard to compare a UP application
vs. the same app. converted to use threads.  Unless the app. is
structured such that multiple threads can run at the same time then
no, you won't see any improvement by going to SMP, in fact a true
single threaded app. will frequently slow down when run on an SMP
kernel.

Have you watched a CPU meter while your benchmark runs?  Even something
basic like `top' should give you a feel for whether or not your
using all of the CPU's.


On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote:
> Hi,
> 
> I have two questions on Linux pthread related issues. Would anyone be able 
> to help?
> 
> ...
>
> 2. We ran multi-threaded application using Linux pthread library on 2-way 
> SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see 
> significant increase in context switching when moving from UP to SMP, and 
> high CPU usage with no performance gain in turns of actual work being done 
> when moving to SMP, despite the fact the benchmark we are running is 
> CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks 
> went to scheduling and signaling overheads. Has anyone seen something like 
> this before with pthread applications running on SMP platforms? Any 
> suggestions or pointers on this subject?
> 
> Thanks a lot!
> 
> Ying
> 
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129495AbRCLFAP>; Mon, 12 Mar 2001 00:00:15 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129496AbRCLFAF>; Mon, 12 Mar 2001 00:00:05 -0500
Received: from [216.161.55.93] ([216.161.55.93]:53757 "EHLO blue.int.wirex.com")
	by vger.kernel.org with ESMTP id <S129495AbRCLE7z>;
	Sun, 11 Mar 2001 23:59:55 -0500
Date: Sun, 11 Mar 2001 21:03:09 -0800
From: Greg KH <greg@wirex.com>
To: Martin Bruchanov <bruchm@pytlik.racom.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010311210309.D19626@wirex.com>
Mail-Followup-To: Greg KH <greg@wirex.com>,
	Martin Bruchanov <bruchm@hnilux.racom.cz>,
	linux-kernel@vger.kernel.org
In-Reply-To: <200103111706.SAA18394@hnilux.racom.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200103111706.SAA18394@hnilux.racom.cz>; from bruchm@hnilux.racom.cz on Sun, Mar 11, 2001 at 06:06:24PM +0100
X-Operating-System: Linux 2.4.2-ac14 (i686)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> 
> Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
> 
> ############################################################################
> [1.] One line summary of the problem:    
> USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.

What kind of motherboard is this?

And does USB work in SMP mode with "noapic" given on the kernel command
line?

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S131481AbRCNRs2>; Wed, 14 Mar 2001 12:48:28 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S131488AbRCNRsS>; Wed, 14 Mar 2001 12:48:18 -0500
Received: from [199.239.160.155] ([199.239.160.155]:9099 "EHLO
	tenchi.datarithm.net") by vger.kernel.org with ESMTP
	id <S131481AbRCNRsG>; Wed, 14 Mar 2001 12:48:06 -0500
Date: Wed, 14 Mar 2001 09:46:34 -0800
From: Robert Read <rread@datarithm.net>
To: Greg KH <greg@wirex.com>, Martin Bruchanov <bruchm@pytlik.racom.cz>,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010314094634.A16482@tenchi.datarithm.net>
Mail-Followup-To: Greg KH <greg@wirex.com>,
	Martin Bruchanov <bruchm@hnilux.racom.cz>,
	linux-kernel@vger.kernel.org
In-Reply-To: <200103111706.SAA18394@hnilux.racom.cz> <20010311210309.D19626@wirex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010311210309.D19626@wirex.com>; from greg@wirex.com on Sun, Mar 11, 2001 at 09:03:09PM -0800
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Mar 11, 2001 at 09:03:09PM -0800, Greg KH wrote:
> On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> > 
> > Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
> > 
> > ############################################################################
> > [1.] One line summary of the problem:    
> > USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.
> 
> What kind of motherboard is this?
> 

>>From the lspci output, looks like I have the same mainboard or at
least one with an identical chipset. I've got an MSI 694D Pro
Mainboard with 694X VIA chipset, with 2 cpus installed, and I had the
same USB problem with 2.4.0, but haven't had time to test it on a
recent kernel.

robert

> And does USB work in SMP mode with "noapic" given on the kernel command
> line?
> 
> thanks,
> 
> greg k-h
> 
> -- 
> greg@(kroah|wirex).com
> http://immunix.org/~greg
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S131535AbRCXBKR>; Fri, 23 Mar 2001 20:10:17 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S131533AbRCXBKI>; Fri, 23 Mar 2001 20:10:08 -0500
Received: from monza.monza.org ([209.102.105.34]:54788 "EHLO monza.monza.org")
	by vger.kernel.org with ESMTP id <S131526AbRCXBKB>;
	Fri, 23 Mar 2001 20:10:01 -0500
Date: Fri, 23 Mar 2001 17:09:01 -0800
From: Tim Wright <timw@splhi.com>
To: dhar <dhar@sawaal.com>
Cc: linux-smp@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010323170901.E2534@kochanski.internal.splhi.com>
Reply-To: timw@splhi.com
Mail-Followup-To: dhar <dhar@sawaal.com>, linux-smp@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <200103240004.FAA15257@email.sawaal.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200103240004.FAA15257@email.sawaal.com>; from dhar@sawaal.com on Sat, Mar 24, 2001 at 05:34:39AM +0530
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hmmm...
you don't really give enough information to make much of a guess.
I'd do the following:
Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost
2.2.19 now, I believe), and build and install that kernel.

Now, if you run into the same problems, record the crash details, especially
if the kernels oopses, and then send the information (kernel version, output
of ksymoops if there is an oops, kernel .config used etc.) to the mailing list.

Tim

On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote:
> Hi,
> 
> I am not a member of either of these lists and would appreciate if you could send your replies to me personally.
> 
> Now the problem:
> 
> I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 2.2.14 with SMP support. NFS was however compiled as a module. 
> 
> Now the problem is as follows:
> 
> Most of the times the machine just works fine. 
> But whenever there is heavy disk write activity it just hangs/crashes. Also this is when the SMP kernel is used. If I use the normal kernel then there is no problem. 
> 
> Could any one tell me what has to be done to prevent this from happening? 
> 
> Any help in this regard will be very much appreciated.
> 
> Once again, kindly reply to me personally as I am not a member of either of these lists.
>  
> Regards
> Dhar 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S132743AbRDINXg>; Mon, 9 Apr 2001 09:23:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S132746AbRDINX0>; Mon, 9 Apr 2001 09:23:26 -0400
Received: from lacrosse.corp.redhat.com ([207.175.42.154]:48503 "EHLO
	lacrosse.corp.redhat.com") by vger.kernel.org with ESMTP
	id <S132743AbRDINXK>; Mon, 9 Apr 2001 09:23:10 -0400
Date: Mon, 9 Apr 2001 14:23:04 +0100
From: Tim Waugh <twaugh@redhat.com>
To: Jakob Kemi <jakob.kemi@post.utfors.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010409142304.H1136@redhat.com>
In-Reply-To: <3.0.1.32.20010402212043.00dadd18@post.utfors.se>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="QDd5rp1wjxlDmy9q"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.1.32.20010402212043.00dadd18@post.utfors.se>; from jakob.kemi@post.utfors.se on Mon, Apr 02, 2001 at 09:20:43PM +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--QDd5rp1wjxlDmy9q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Apr 02, 2001 at 09:20:43PM +0200, Jakob Kemi wrote:

> Ok, maybe this isn't the right list for this question. In 2.2.x the
> parport_probe module extracted the ieee1284 device id correctly and
> added to the proc fs. However this doesn't seem to work for me in
> 2.4.x

It changed place: perhaps that's the problem?  /proc/parport/$n is now
/proc/sys/dev/parport/$name.

> Is there some option I need to enable. As far as I understand the
>  CONFIG_PARPORT_1284 should be enough??

Yes, it should.

Tim.
*/

--QDd5rp1wjxlDmy9q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE60be4ONXnILZ4yVIRAvFSAJ9r9+t8auFaSs7I8100A8R18M7QagCgmN17
QJQPUkHUnnFS8e6tgR3fBd0=
=eDcm
-----END PGP SIGNATURE-----

--QDd5rp1wjxlDmy9q--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S131638AbRDZTwZ>; Thu, 26 Apr 2001 15:52:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135520AbRDZTwQ>; Thu, 26 Apr 2001 15:52:16 -0400
Received: from mailhst2.its.tudelft.nl ([130.161.34.250]:16901 "EHLO
	mailhst2.its.tudelft.nl") by vger.kernel.org with ESMTP
	id <S131638AbRDZTwM>; Thu, 26 Apr 2001 15:52:12 -0400
Date: Thu, 26 Apr 2001 21:51:23 +0200
From: Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL>
To: Alexandru Barloiu Nicolae <axl@light.kappa.ro>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010426215123.A24146@arthur.ubicom.tudelft.nl>
In-Reply-To: <001b01c0ce88$5632fc70$e8c6e7c1@scream>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001b01c0ce88$5632fc70$e8c6e7c1@scream>; from axl@light.kappa.ro on Thu, Apr 26, 2001 at 10:37:32PM +0300
Organization: Eric Conspiracy Secret Labs
X-Eric-Conspiracy: There is no conspiracy!
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 26, 2001 at 10:37:32PM +0300, Alexandru Barloiu Nicolae wrote:
> is ftp.kernel.org down or is just my connections fault ?

Yes, scheduled downtime. Use your local mirror (ftp.ro.kernel.org).


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135313AbRDZTzz>; Thu, 26 Apr 2001 15:55:55 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135477AbRDZTzp>; Thu, 26 Apr 2001 15:55:45 -0400
Received: from viper.haque.net ([66.88.179.82]:38538 "EHLO mail.haque.net")
	by vger.kernel.org with ESMTP id <S135313AbRDZTzd>;
	Thu, 26 Apr 2001 15:55:33 -0400
Date: Thu, 26 Apr 2001 15:54:41 -0400 (EDT)
From: "Mohammad A. Haque" <mhaque@haque.net>
To: Alexandru Barloiu Nicolae <axl@light.kappa.ro>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <001b01c0ce88$5632fc70$e8c6e7c1@scream>
Message-ID: <Pine.LNX.4.33.0104261554250.14065-100000@viper.haque.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Down for maint.


On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:

> is ftp.kernel.org down or is just my connections fault ?
>

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135902AbRDZUAf>; Thu, 26 Apr 2001 16:00:35 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135477AbRDZUAT>; Thu, 26 Apr 2001 16:00:19 -0400
Received: from twin.uoregon.edu ([128.223.214.27]:50827 "EHLO twin.uoregon.edu")
	by vger.kernel.org with ESMTP id <S135902AbRDZUAE>;
	Thu, 26 Apr 2001 16:00:04 -0400
Date: Thu, 26 Apr 2001 12:59:53 -0700 (PDT)
From: Joel Jaeggli <joelja@darkwing.uoregon.edu>
X-X-Sender: <joelja@twin.uoregon.edu>
To: Alexandru Barloiu Nicolae <axl@light.kappa.ro>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <001b01c0ce88$5632fc70$e8c6e7c1@scream>
Message-ID: <Pine.LNX.4.33.0104261259360.3851-100000@twin.uoregon.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

yeah two hour upgrade window today...

joelja

On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:

> is ftp.kernel.org down or is just my connections fault ?
>
> axl
>
>
> ______________________________________________________
> support slackware anyway posible paypal@slackware.com anyone ?
>    http://www.slackware.com/forum/read.php?f=5&i=7887&t=7887
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S136091AbRECALS>; Wed, 2 May 2001 20:11:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S136092AbRECALI>; Wed, 2 May 2001 20:11:08 -0400
Received: from neon-gw.transmeta.com ([209.10.217.66]:10254 "EHLO
	neon-gw.transmeta.com") by vger.kernel.org with ESMTP
	id <S136091AbRECAK4>; Wed, 2 May 2001 20:10:56 -0400
Date: Wed, 2 May 2001 17:10:31 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Duc Vianney <dvianney@us.ibm.com>
cc: <castortz@nmu.edu>, Bill Hartner <bhartner@us.ibm.com>,
        <staelin@hpl.hp.com>, Larry McVoy <lm@bitmover.com>,
        <lse-tech@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>,
        <lmbench-users@bitmover.com>
Subject: Re: your mail
In-Reply-To: <OF8F1A4043.9087C91A-ON85256A40.0079DA30@raleigh.ibm.com>
Message-ID: <Pine.LNX.4.31.0105021658170.24914-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Wed, 2 May 2001, Duc Vianney wrote:
>
> Has anyone seen performance degradations between 2.2.19 and 2.4.x

Yes.

The signal handling one is because 2.4.x will save off the full SSE2
state, which means that the signal stack is almost 700 bytes, as compared
to <200 before. This is sadly necessary to be able to take advantage of
the SSE2 instructions - and on special applications the win can be quite
noticeable. This one you won't be able to avoid, although you shouldn't
see it on older hardware that do not have SSE2 (you see it because you
have a PIII).

You don't say how much memory you have, but the file handling ones might
be due to a really unfortunate hash thinko that cause the dentry hash to
be pretty much useless on machines that have 512MB of RAM (it can show up
in other cases, but 512M is the case that makes the hash really become a
non-hash). If so, it should be fixed in 2.4.2.

2.4.4 will give noticeably better numbers for fork and fork+exec. However,
the scheduling optimization that does that actually breaks at least
"bash", and it appears that we will just undo it during the stable series.
Even if the bug is obviously in user land (and a fix is available), stable
kernels shouldn't try to hide the problems.

			Linus


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S136103AbREGMJ6>; Mon, 7 May 2001 08:09:58 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S136098AbREGMJi>; Mon, 7 May 2001 08:09:38 -0400
Received: from mailhst2.its.tudelft.nl ([130.161.34.250]:2313 "EHLO
	mailhst2.its.tudelft.nl") by vger.kernel.org with ESMTP
	id <S136094AbREGMJ3>; Mon, 7 May 2001 08:09:29 -0400
Date: Mon, 7 May 2001 14:09:14 +0200
From: Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL>
To: Chandrashekar Nagaraj <chandrashekar.nag@wipro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010507140914.K18405@arthur.ubicom.tudelft.nl>
In-Reply-To: <004101c0d6ea$44ec44c0$4433a8c0@wipro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <004101c0d6ea$44ec44c0$4433a8c0@wipro.com>; from chandrashekar.nag@wipro.com on Mon, May 07, 2001 at 05:08:43PM +0530
Organization: Eric Conspiracy Secret Labs
X-Eric-Conspiracy: There is no conspiracy!
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, May 07, 2001 at 05:08:43PM +0530, Chandrashekar Nagaraj wrote:
> 	i want to know how to read tab without a terminating character,
> ie., if i use getchar() i have to enter '\n' after tab to read tab,
> same is the case with read system call and scanf. 

This is off topic for this list, but anyway.

Read man cfmakeraw, and/or get a copy of "Advanced programming in the
UNIX environment" by W. Richard Stevens.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135239AbREHUI1>; Tue, 8 May 2001 16:08:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135363AbREHUIK>; Tue, 8 May 2001 16:08:10 -0400
Received: from ns.virtualhost.dk ([195.184.98.160]:20230 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id <S135239AbREHUHB>;
	Tue, 8 May 2001 16:07:01 -0400
Date: Tue, 8 May 2001 22:06:43 +0200
From: Jens Axboe <axboe@suse.de>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20010508220643.S505@suse.de>
In-Reply-To: <Pine.LNX.3.95.1010508154726.29540A-100000@chaos.analogic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.3.95.1010508154726.29540A-100000@chaos.analogic.com>; from root@chaos.analogic.com on Tue, May 08, 2001 at 03:48:45PM -0400
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 08 2001, Richard B. Johnson wrote:
> 
> To driver wizards:
> 
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
> 
> It needs to get some CPU time which can be "turned on" or
> "turned off" as a result of an interrupt or some external
> input from  an ioctl().
> 
> So I thought that the "tasklet" would be ideal. However, the
> scheduler "thinks" that a tasklet is an interrupt, so any
> attempt to sleep in the tasklet results in a kernel panic,
> "ieee scheduling in an interrupt..., BUG sched.c line 688".

Use a kernel thread? If you don't need to access user space, context
switches are very cheap.

> So, what am I supposed to do to add a piece of driver code to the
> run queue so it gets scheduled occasionally?

Several, grep for kernel_thread.

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135242AbREHUP2>; Tue, 8 May 2001 16:15:28 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135256AbREHUPR>; Tue, 8 May 2001 16:15:17 -0400
Received: from chaos.analogic.com ([204.178.40.224]:15489 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S135242AbREHUPN>; Tue, 8 May 2001 16:15:13 -0400
Date: Tue, 8 May 2001 16:15:06 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Jens Axboe <axboe@suse.de>
cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20010508220643.S505@suse.de>
Message-ID: <Pine.LNX.3.95.1010508161252.29954A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 8 May 2001, Jens Axboe wrote:

> On Tue, May 08 2001, Richard B. Johnson wrote:
> > 
> > To driver wizards:
> > 
> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> > 
> > It needs to get some CPU time which can be "turned on" or
> > "turned off" as a result of an interrupt or some external
> > input from  an ioctl().
> > 
> > So I thought that the "tasklet" would be ideal. However, the
> > scheduler "thinks" that a tasklet is an interrupt, so any
> > attempt to sleep in the tasklet results in a kernel panic,
> > "ieee scheduling in an interrupt..., BUG sched.c line 688".
> 
> Use a kernel thread? If you don't need to access user space, context
> switches are very cheap.
> 
> > So, what am I supposed to do to add a piece of driver code to the
> > run queue so it gets scheduled occasionally?
> 
> Several, grep for kernel_thread.
> 
> -- 
> Jens Axboe
> 

Okay. Thanks. I thought I would have to do that too. No problem.
It's a "tomorrow" thing. Ten hours it too long to stare at a
screen.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135256AbREHUR1>; Tue, 8 May 2001 16:17:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135263AbREHURH>; Tue, 8 May 2001 16:17:07 -0400
Received: from ns.virtualhost.dk ([195.184.98.160]:25094 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id <S135256AbREHURA>;
	Tue, 8 May 2001 16:17:00 -0400
Date: Tue, 8 May 2001 22:16:43 +0200
From: Jens Axboe <axboe@suse.de>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20010508221643.T505@suse.de>
In-Reply-To: <20010508220643.S505@suse.de> <Pine.LNX.3.95.1010508161252.29954A-100000@chaos.analogic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.3.95.1010508161252.29954A-100000@chaos.analogic.com>; from root@chaos.analogic.com on Tue, May 08, 2001 at 04:15:06PM -0400
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 08 2001, Richard B. Johnson wrote:
> > Use a kernel thread? If you don't need to access user space, context
> > switches are very cheap.
> > 
> > > So, what am I supposed to do to add a piece of driver code to the
> > > run queue so it gets scheduled occasionally?
> > 
> > Several, grep for kernel_thread.
> > 
> > -- 
> > Jens Axboe
> > 
> 
> Okay. Thanks. I thought I would have to do that too. No problem.

A small worker thread and a wait queue to sleeep on and you are all set,
10 minutes tops :-)

> It's a "tomorrow" thing. Ten hours it too long to stare at a
> screen.

Sissy!

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135306AbREHUnL>; Tue, 8 May 2001 16:43:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135318AbREHUnB>; Tue, 8 May 2001 16:43:01 -0400
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:28677 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S135306AbREHUmv>; Tue, 8 May 2001 16:42:51 -0400
Subject: Re: your mail
To: root@chaos.analogic.com
Date: Tue, 8 May 2001 21:46:48 +0100 (BST)
Cc: linux-kernel@vger.kernel.org (Linux kernel)
In-Reply-To: <Pine.LNX.3.95.1010508154726.29540A-100000@chaos.analogic.com> from "Richard B. Johnson" at May 08, 2001 03:48:45 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14xENe-0000aK-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.

Wht does it have to wait ? Why cant it just poll and come back next time ?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S135403AbREHVGL>; Tue, 8 May 2001 17:06:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S135404AbREHVGC>; Tue, 8 May 2001 17:06:02 -0400
Received: from chaos.analogic.com ([204.178.40.224]:17537 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S135403AbREHVFt>; Tue, 8 May 2001 17:05:49 -0400
Date: Tue, 8 May 2001 17:05:27 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <E14xENe-0000aK-00@the-village.bc.nu>
Message-ID: <Pine.LNX.3.95.1010508164343.30336A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 8 May 2001, Alan Cox wrote:

> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> 
> Wht does it have to wait ? Why cant it just poll and come back next time ?
> 

Good question. I wanted to be able to call the exact same routine(s)
that other routines (exected from read() and write()), execute.
These routines are complex and sleep while waiting for events. I
didn't want to duplicate that code with different time-out mechanisms.

GPIB is nasty because you can't do anything unless the 'controller'
tells you to do it. When "addressed to talk", you have to parse
all the stuff sent via interrupt (ATN bit set, control byte, which
address from the control byte, etc.), then let somebody sleeping
in poll() know that they can now "write()". That can all be handled
via interrupt. But, now for the receive <grin>. The user-mode code
needs to be sleeping until some data are available. That data
may never be available. Something in the driver needs to wait
until the hardware is addressed to receive. Since it is not now
receiving, there is no interrupt! It takes time for the controller
to tell you to listen and then tell somebody else to talk to you.
This means that I need some timeout to recover from the fact
that the other guy may never talk.

Once the other guy starts sending data, the interrupts can be
used to handle the data and, once there are valid data, the
device owner can be awakened, presumably sleeping in poll() or
select(). It's the intermediate time where there are no
interrupts that needs the CPU to determine that we've waited
too long for interrupts so the device had better get off the
bus to start the error recovery procedure.

Bright an early tommorrow, I will check out both ways. A kernel
thread might be "neat". However, I may just look to see if
I can just poll while using existing code.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S136460AbREIN7Z>; Wed, 9 May 2001 09:59:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S136461AbREIN7P>; Wed, 9 May 2001 09:59:15 -0400
Received: from chaos.analogic.com ([204.178.40.224]:54401 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S136460AbREIN7F>; Wed, 9 May 2001 09:59:05 -0400
Date: Wed, 9 May 2001 09:59:00 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Jens Axboe <axboe@suse.de>
cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20010508221643.T505@suse.de>
Message-ID: <Pine.LNX.3.95.1010509095722.8944A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 8 May 2001, Jens Axboe wrote:

> On Tue, May 08 2001, Richard B. Johnson wrote:
> > > Use a kernel thread? If you don't need to access user space, context
> > > switches are very cheap.
> > > 
> > > > So, what am I supposed to do to add a piece of driver code to the
> > > > run queue so it gets scheduled occasionally?
> > > 
> > > Several, grep for kernel_thread.
> > > 
> > > -- 
> > > Jens Axboe
> > > 
> > 
> > Okay. Thanks. I thought I would have to do that too. No problem.
> 
> A small worker thread and a wait queue to sleeep on and you are all set,
> 10 minutes tops :-)
> 
> > It's a "tomorrow" thing. Ten hours it too long to stare at a
> > screen.
> 
> Sissy!
> 

Okay. I am now awake. I will now try the kernel thread. Looks
simple. Got to remember to kill it before/during module removal.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261348AbREQATW>; Wed, 16 May 2001 20:19:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261346AbREQATM>; Wed, 16 May 2001 20:19:12 -0400
Received: from mailhst2.its.tudelft.nl ([130.161.34.250]:41481 "EHLO
	mailhst2.its.tudelft.nl") by vger.kernel.org with ESMTP
	id <S261277AbREQATJ>; Wed, 16 May 2001 20:19:09 -0400
Date: Thu, 17 May 2001 02:11:21 +0200
From: Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL>
To: siva prasad <si_pras@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010517021119.C12745@arthur.ubicom.tudelft.nl>
In-Reply-To: <20010516150538.20451.qmail@web13703.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010516150538.20451.qmail@web13703.mail.yahoo.com>; from si_pras@yahoo.com on Wed, May 16, 2001 at 08:05:38AM -0700
Organization: Eric Conspiracy Secret Labs
X-Eric-Conspiracy: There is no conspiracy!
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, May 16, 2001 at 08:05:38AM -0700, siva prasad wrote:
> Is it true that the ipc calls like
> msgget(),shmget()...
> are  not really system calls?

No, they all use a system call, but the system call is the same for all
functions.

> Cos in the file "asm/unistd.h" where the
> system calls are listed as __NR_xxx we dont find
> the appropriate listing for the ipc calls.
> What I guessed was that all the ipc calls are
> clubbed under the 'int ipc()' system call and this
> is well listed in the "asm/unistd.h" 

Right, they all use __NR_ipc. See sys_ipc() in
arch/i386/kernel.sys_i386.c, especially the comment right above the
function...

> Could some one explain why the ipc is implemented 
> this way rather that implementing them as individual 
> system calls as in UNIX.

Probably because the original designer liked it this way and nobody
cared enough to do it otherwise.

> Or is it the same way in UNIX

I don't know, I don't have Unix source available.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261651AbREUUNG>; Mon, 21 May 2001 16:13:06 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261665AbREUUM4>; Mon, 21 May 2001 16:12:56 -0400
Received: from a-pr4-46.tin.it ([212.216.131.173]:36224 "EHLO
	eris.discordia.loc") by vger.kernel.org with ESMTP
	id <S261651AbREUUMp>; Mon, 21 May 2001 16:12:45 -0400
Date: Mon, 21 May 2001 22:12:23 +0200 (CEST)
From: Lorenzo Marcantonio <lomarcan@tin.it>
To: Thomas Palm <palm4711@gmx.de>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <19729.990474214@www36.gmx.net>
Message-ID: <Pine.LNX.4.31.0105212209480.845-100000@eris.discordia.loc>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 21 May 2001, Thomas Palm wrote:

> there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> including Sound + Raid). My tests:
> 1st run of "diff -r srcdir destdir" -> no differs
> 2nd run of "diff -r srcdir destdir" -> 2 files differ
> 3rd run of "diff -r srcdir destdir" -> 1 file differs
> 4th run of "diff -r srcdir destdir" -> 1 file differs
> 5th run of "diff -r srcdir destdir" -> no differs

Could you check WHERE the file differ and WHERE the data come from ?

I've got the same mobo AND some nasty DAT tape corruption problems...
(also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
the DMA troubling us...

				-- Lorenzo Marcantonio



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262604AbREVKKa>; Tue, 22 May 2001 06:10:30 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262605AbREVKKU>; Tue, 22 May 2001 06:10:20 -0400
Received: from mx0.gmx.net ([213.165.64.100]:24004 "HELO mx0.gmx.net")
	by vger.kernel.org with SMTP id <S262604AbREVKKG>;
	Tue, 22 May 2001 06:10:06 -0400
Date: Tue, 22 May 2001 12:06:52 +0200 (MEST)
From: Thomas Palm <palm4711@gmx.de>
To: Lorenzo Marcantonio <lomarcan@tin.it>
Cc: linux-kernel@vger.kernel.org
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.31.0105212209480.845-100000@eris.discordia.loc>
Subject: Re: your mail
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0009482897@gmx.net
X-Authenticated-IP: [193.159.61.153]
Message-ID: <2567.990526012@www38.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

1. The corrupted files have the same length but differ (I cannot say on what
bit-position)
2. I reproduced the problem while burning CD from SCSI-Disk to
SCSI-CD-Burner!!!
-> It´s definetly not a (single?) IDE-Problem

Burning CD (on slow 4x speed) seems to initialize many small transfers
(instead of a smooth stream)(same as copying many small files) on PCI/DMA wich
generate the same problems!!!



> On Mon, 21 May 2001, Thomas Palm wrote:
> 
> > there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> > including Sound + Raid). My tests:
> > 1st run of "diff -r srcdir destdir" -> no differs
> > 2nd run of "diff -r srcdir destdir" -> 2 files differ
> > 3rd run of "diff -r srcdir destdir" -> 1 file differs
> > 4th run of "diff -r srcdir destdir" -> 1 file differs
> > 5th run of "diff -r srcdir destdir" -> no differs
> 
> Could you check WHERE the file differ and WHERE the data come from ?
> 
> I've got the same mobo AND some nasty DAT tape corruption problems...
> (also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
> the DMA troubling us...
> 
> 				-- Lorenzo Marcantonio
> 
> 

-- 
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S263246AbREaWBl>; Thu, 31 May 2001 18:01:41 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S263251AbREaWBc>; Thu, 31 May 2001 18:01:32 -0400
Received: from green.mif.pg.gda.pl ([153.19.42.8]:17680 "EHLO
	green.mif.pg.gda.pl") by vger.kernel.org with ESMTP
	id <S263246AbREaWBT>; Thu, 31 May 2001 18:01:19 -0400
From: Andrzej Krzysztofowicz <kufel!ankry@green.mif.pg.gda.pl>
Message-Id: <200105312037.WAA01610@kufel.dom>
Subject: Re: your mail
To: kufel!tais.toshiba.com!Ramil.Santamaria@green.mif.pg.gda.pl
Date: Thu, 31 May 2001 22:37:54 +0200 (CEST)
Cc: kufel!vger.kernel.org!linux-kernel@green.mif.pg.gda.pl
In-Reply-To: <OFCA65A58C.155A1FB1-ON88256A5D.005BDA7A@tais.net> from "Ramil.Santamaria@tais.toshiba.com" at May 31, 2001 09:53:43 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> 
> Minor issue with bootsect.s.

1. bootsect.S is the source file

> The single instance of the lds assembly instruction includes the comment of
> !  ds:si is source
> ...
> seg fs
> lds  si,(bx)        !     ds:si is source
> ...
> Is this comment not in reverse order (i.e should be lds
> dest,src)................

2. This is not a comment of i386 mnemonics. This comments the role of
   specific register in the following instructions.

BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
counter 32-bit here? This would enable using the simple bootloader for
greater kernel loading...  (current limit is sligtly below 1MB)
Possibly some 16/32-bit real mode code mixing would be necessary.

Andrzej

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S263276AbREaXE6>; Thu, 31 May 2001 19:04:58 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S263269AbREaXEs>; Thu, 31 May 2001 19:04:48 -0400
Received: from neon-gw.transmeta.com ([209.10.217.66]:37135 "EHLO
	neon-gw.transmeta.com") by vger.kernel.org with ESMTP
	id <S263281AbREaXEg>; Thu, 31 May 2001 19:04:36 -0400
To: linux-kernel@vger.kernel.org
From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: your mail
Date: 31 May 2001 16:04:04 -0700
Organization: Transmeta Corporation, Santa Clara CA
Message-ID: <9f6il4$ts6$1@cesium.transmeta.com>
In-Reply-To: <OFCA65A58C.155A1FB1-ON88256A5D.005BDA7A@tais.net> <200105312037.WAA01610@kufel.dom>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Disclaimer: Not speaking for Transmeta in any way, shape, or form.
Copyright: Copyright 2001 H. Peter Anvin - All Rights Reserved
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Followup to:  <200105312037.WAA01610@kufel.dom>
By author:    Andrzej Krzysztofowicz <kufel!ankry@green.mif.pg.gda.pl>
In newsgroup: linux.dev.kernel
> 
> BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
> counter 32-bit here? This would enable using the simple bootloader for
> greater kernel loading...  (current limit is sligtly below 1MB)
> Possibly some 16/32-bit real mode code mixing would be necessary.
> 

PLEASE don't go there.  bootsect.S is fundamentally broken these days
(doesn't work on USB floppies, for example.)  It should be killed
DEAD, DEAD, DEAD and not dragged along like a dead albatross.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261515AbRFMJdH>; Wed, 13 Jun 2001 05:33:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262170AbRFMJc5>; Wed, 13 Jun 2001 05:32:57 -0400
Received: from Expansa.sns.it ([192.167.206.189]:21261 "EHLO Expansa.sns.it")
	by vger.kernel.org with ESMTP id <S261515AbRFMJcm>;
	Wed, 13 Jun 2001 05:32:42 -0400
Date: Wed, 13 Jun 2001 11:32:35 +0200 (CEST)
From: Luigi Genoni <kernel@Expansa.sns.it>
To: Colonel <klink@clouddancer.com>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20010613015519.151BF78599@mail.clouddancer.com>
Message-ID: <Pine.LNX.4.33.0106131130200.22415-100000@Expansa.sns.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

I have the sound blaster 16 card on one of my athlon (on PIII i have
es1731), that has one isa slot on its MB.
It works well, but i do not use isapnp nor any pnp support is enabled
inside of the kernel.
running 2.4.5/2.4.6-pre2

Luigi


On Tue, 12 Jun 2001, Colonel wrote:

> From: Colonel <klink@clouddancer.com>
> To: linux-kernel@vger.kernel.org
> Subject: ISA Soundblaster problem
> Reply-to: klink@clouddancer.com
>
>
> The Maintainers list does not contain anyone for 2.4 Soundblaster
> modules, so perhaps some one on the mailing list is aware of a
> solution.  My ISA Soundblaster 16waveffects worked fine in kernel 2.2
> with XMMS.  But I have never been successful in a varity of 2.4
> kernels, the latest being 2.4.5-ac12.  This is what I know:
>
> [DMESG]
> isapnp: Scanning for PnP cards...
> isapnp: Calling quirk for 01:00
> isapnp: SB audio device quirk - increasing port range
> isapnp: Card 'Creative SB16 PnP'
> isapnp: 1 Plug & Play card detected total
>
> }modprobe sb
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
>
>
> [/etc/modules.conf]
> options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
>
>
> [DMESG}
> Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
> sb: No ISAPnP cards found, trying standard ones...
> sb: dsp reset failed.
>
>
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail.  Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
>
>
>
> TIA
>
>
> please CC:  klink@clouddancer.com, not currently on the mailing list.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S263980AbRFRN4K>; Mon, 18 Jun 2001 09:56:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S263978AbRFRN4C>; Mon, 18 Jun 2001 09:56:02 -0400
Received: from artax.karlin.mff.cuni.cz ([195.113.31.125]:25107 "EHLO
	artax.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP
	id <S263970AbRFRNz4>; Mon, 18 Jun 2001 09:55:56 -0400
Date: Mon, 18 Jun 2001 15:55:31 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Colonel <klink@clouddancer.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20010618155531.A21070@artax.karlin.mff.cuni.cz>
In-Reply-To: <20010613015519.151BF78599@mail.clouddancer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010613015519.151BF78599@mail.clouddancer.com>; from klink@clouddancer.com on Tue, Jun 12, 2001 at 06:55:19PM -0700
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail.  Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
> 
> 
> Anyone have a solution?
> 
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...

I had a similar problem with different card (Gravi Usltrasound PnP).
The solution turned out to be to avoid dma 1 channel. May be some BIOSes
or ISA chipsets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267505AbRGXMsL>; Tue, 24 Jul 2001 08:48:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267513AbRGXMsC>; Tue, 24 Jul 2001 08:48:02 -0400
Received: from chaos.analogic.com ([204.178.40.224]:3714 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S267505AbRGXMrw> convert rfc822-to-8bit; Tue, 24 Jul 2001 08:47:52 -0400
Date: Tue, 24 Jul 2001 08:47:39 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: =?gb2312?q?=D0=C2=20=D4=C2?= <xinyuepeng@yahoo.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20010724003806.59752.qmail@web20009.mail.yahoo.com>
Message-ID: <Pine.LNX.3.95.1010724084559.26144B-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Original-Recipient: rfc822;linux-kernel-outgoing

On Tue, 24 Jul 2001, [gb2312] ĐÂ ÔÂ wrote:

> Hi:
> 	how does the kernel know which filesystem should be
> mounted as root filesytem?
> 

The Easter Bunny whispers in its ear.... Erm actually, check
/etc/lilo.conf for hints.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S275387AbRJBPqD>; Tue, 2 Oct 2001 11:46:03 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S273709AbRJBPpy>; Tue, 2 Oct 2001 11:45:54 -0400
Received: from gap.cco.caltech.edu ([131.215.139.43]:5825 "EHLO
	gap.cco.caltech.edu") by vger.kernel.org with ESMTP
	id <S275389AbRJBPpj>; Tue, 2 Oct 2001 11:45:39 -0400
Subject: Re: your mail
To: dinesh_gandhewar@rediffmail.com
Date: Tue, 2 Oct 2001 16:30:05 +0100 (BST)
Cc: mlist-linux-kernel@nntp-server.caltech.edu
In-Reply-To: <20011002152945.15180.qmail@mailweb16.rediffmail.com> from "Dinesh  Gandhewar" at Oct 02, 2001 03:29:45 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E15oRUj-000512-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
> Can you explain this behaviour?

Yes
--
Alan

[Oh wait you want to know why...]

Either

1.	You are using it for DMA
2.	You are putting it on the stack and causing a stack overflow


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S275389AbRJBQRU>; Tue, 2 Oct 2001 12:17:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S275529AbRJBQRC>; Tue, 2 Oct 2001 12:17:02 -0400
Received: from gap.cco.caltech.edu ([131.215.139.43]:7618 "EHLO
	gap.cco.caltech.edu") by vger.kernel.org with ESMTP
	id <S275389AbRJBQQ5>; Tue, 2 Oct 2001 12:16:57 -0400
Date: Tue, 2 Oct 2001 11:52:31 -0400
From: "Michael H. Warfield" <mhw@wittsend.com>
To: Dinesh Gandhewar <dinesh_gandhewar@rediffmail.com>
Cc: mlist-linux-kernel@NNTP-SERVER.CALTECH.EDU
Subject: Re: your mail
Message-ID: <20011002115231.A26095@alcove.wittsend.com>
Mail-Followup-To: Dinesh Gandhewar <dinesh_gandhewar@rediffmail.com>,
	mlist-linux-kernel@nntp-server.caltech.edu
In-Reply-To: <20011002152945.15180.qmail@mailweb16.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011002152945.15180.qmail@mailweb16.rediffmail.com>
User-Agent: Mutt/1.3.20i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Oct 02, 2001 at 03:29:45PM -0000, Dinesh  Gandhewar wrote:

> Hello,
> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this
	array, the execution of this module function causes kernel to
	reboot. If I kmalloc() this array then execution of this module
	function doesnot cause any problem.
> Can you explain this behaviour?

	You didn't say how you declared the array or what the element
size was.  If the array elements were larger than a char, by saying an
array of size 2048, do you mean in bytes or in array elements?

	You also didn't say where you called your module from.  Was it
in an interrupt handler or at insmod time or from a system call.

	If it was a automatic array on the stack (declared inside the
function and not declared static), you probably overflowed the stack.

> Thnaks,
> Dinesh 

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S275381AbRJBQQk>; Tue, 2 Oct 2001 12:16:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S275576AbRJBQQa>; Tue, 2 Oct 2001 12:16:30 -0400
Received: from gap.cco.caltech.edu ([131.215.139.43]:7618 "EHLO
	gap.cco.caltech.edu") by vger.kernel.org with ESMTP
	id <S275389AbRJBQQV>; Tue, 2 Oct 2001 12:16:21 -0400
Date: Tue, 2 Oct 2001 11:49:20 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Dinesh Gandhewar <dinesh_gandhewar@rediffmail.com>
cc: mlist-linux-kernel@NNTP-SERVER.CALTECH.EDU
Subject: Re: your mail
In-Reply-To: <20011002152945.15180.qmail@mailweb16.rediffmail.com>
Message-ID: <Pine.LNX.3.95.1011002113741.8413A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 2 Oct 2001, Dinesh  Gandhewar wrote:

> 
> Hello,
> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this
> array, the execution of this module function causes kernel to reboot.
> If I kmalloc() this array then execution of this module function
> doesnot cause any problem.
> Can you explain this behaviour?
> Thnaks,
> Dinesh 

I would check that you are not accidentally exceeding the bounds of
your array. Actual allocation occurs in page-size chunks. You may
be exceeding your 2048 byte-limit without exceeding the 4096-byte
page-size (of ix86).

However, a global array, or an array on the stack, has very strict
limits. You can blow things up on the stack by exceeding an array
boundary by one byte. And you can overwrite important memory objects
by exceeding the bounds of a global memory object.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S277316AbRJOHSf>; Mon, 15 Oct 2001 03:18:35 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S277317AbRJOHSZ>; Mon, 15 Oct 2001 03:18:25 -0400
Received: from gap.cco.caltech.edu ([131.215.139.43]:58499 "EHLO
	gap.cco.caltech.edu") by vger.kernel.org with ESMTP
	id <S277316AbRJOHSI>; Mon, 15 Oct 2001 03:18:08 -0400
From: Tim Hockin <thockin@hockin.org>
Message-Id: <200110150631.f9F6Viu14212@www.hockin.org>
Subject: Re: your mail
To: dinesh_gandhewar@rediffmail.com
Date: Sun, 14 Oct 2001 23:31:44 -0700 (PDT)
Cc: mlist-linux-kernel@nntp-server.caltech.edu
In-Reply-To: <20011015062505.32762.qmail@mailweb33.rediffmail.com> from "Dinesh  Gandhewar" at Oct 15, 2001 06:25:05 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> What is the effect of following statement at the end of function definition?
> *(int *)0 = 0;	

to cause a crash - you can't derefernce a pointer whose value is 0 (NULL).



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S282728AbRLGFQ3>; Fri, 7 Dec 2001 00:16:29 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S282736AbRLGFQU>; Fri, 7 Dec 2001 00:16:20 -0500
Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:31758 "EHLO
	neon-gw.transmeta.com") by vger.kernel.org with ESMTP
	id <S282728AbRLGFQD>; Fri, 7 Dec 2001 00:16:03 -0500
Date: Thu, 6 Dec 2001 21:10:11 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
To: Keith Owens <kaos@ocs.com.au>
cc: <kbuild-devel@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <24493.1007698673@kao2.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.33.0112062109400.7866-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


On Fri, 7 Dec 2001, Keith Owens wrote:
>
> Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.

We're getting the block IO layer in shape first, the time has not come for
_anything_ else before that.

		Linus


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S285481AbRLNTlH>; Fri, 14 Dec 2001 14:41:07 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S285475AbRLNTks>; Fri, 14 Dec 2001 14:40:48 -0500
Received: from mail.libertysurf.net ([213.36.80.91]:23841 "EHLO
	mail.libertysurf.net") by vger.kernel.org with ESMTP
	id <S285481AbRLNTkm> convert rfc822-to-8bit; Fri, 14 Dec 2001 14:40:42 -0500
Date: Fri, 14 Dec 2001 17:46:37 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
X-X-Sender: <groudier@gerard>
To: =?iso-8859-1?q?Kirk=20Alexander?= <kirkalx@yahoo.co.nz>
cc: Jens Axboe <axboe@suse.de>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011214041151.91557.qmail@web14904.mail.yahoo.com>
Message-ID: <20011214172419.Q1591-100000@gerard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Fri, 14 Dec 2001, Kirk Alexander wrote:

> [cc'ed to lkml and Gerard Roudier]
>
> Hi Jens,
>
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
>
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver.

Use sym53c8xx_2 instead. This one uses 2 different firmwares,

- one based on sym53c8xx driver scripts called
  'LOAD/STORE based' firmware,
- and another one that only uses generic scripts instructions
  and called 'GENERIC' firmware.

The GENERIC firmware has worked for me witn a 810 rev. 2.

I haven't this controller installed at the moment, but I can test the
driver by forcing the driver to use the GENERIC scripts instead for any
symbios chip.

You may let me know if sym53c8xx_2 still works with 810 rev 2.

> I fixed the problem by seeing what the sym
> driver did i.e. the patch below
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.

The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
reliability and performance.

  Gérard.

> Cheers,
> Kirk Alexander
>
> P.S.
> Please excuse me if this has already been fixed or
> posted, or if I've broken some lkml etiquette - first
> post I think after lurking off and on for ages. Also
> first time I've compiled a kernel that has only been
> out a few days!

You are welcome and you didn't break any etiquette. The lkml is a very
open mailing list but it gets more than 200 postings a day. Thus the
linux-scsi@vger.kernel.org list should be preferred for topics that
address scsi specifically.


> --- linux/drivers/scsi/sym53c8xx_comm.h	Fri Dec 14
> 16:46:45 2001
> +++ linux/drivers/scsi/sym53c8xx_comm.h	Fri Dec 14
> 16:49:19 2001
> @@ -438,11 +438,20 @@
>  #define	NCR_LOCK_NCB(np, flags)
> spin_lock_irqsave(&np->smp_lock, flags)
>  #define	NCR_UNLOCK_NCB(np, flags)
> spin_unlock_irqrestore(&np->smp_lock, flags)
>
> +#if LINUX_VERSION_CODE >= LinuxVersionCode(2,5,0)
> +
> +#define	NCR_LOCK_SCSI_DONE(np, flags) \
> +		spin_lock_irqsave((np)->done_list->host, flags)
> +#define	NCR_UNLOCK_SCSI_DONE(np, flags) \
> +		spin_unlock_irqrestore((np)->done_list->host,
> flags)
> +#else
> +
>  #define	NCR_LOCK_SCSI_DONE(np, flags) \
>  		spin_lock_irqsave(&io_request_lock, flags)
>  #define	NCR_UNLOCK_SCSI_DONE(np, flags) \
>  		spin_unlock_irqrestore(&io_request_lock, flags)
>
> +#endif
>  #else
>
>  #define	NCR_LOCK_DRIVER(flags)     do {
> save_flags(flags); cli(); } while (0)


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S285490AbRLNUPw>; Fri, 14 Dec 2001 15:15:52 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S285484AbRLNUPn>; Fri, 14 Dec 2001 15:15:43 -0500
Received: from ns.virtualhost.dk ([195.184.98.160]:3087 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id <S285483AbRLNUPf>;
	Fri, 14 Dec 2001 15:15:35 -0500
Date: Fri, 14 Dec 2001 21:09:48 +0100
From: Jens Axboe <axboe@suse.de>
To: =?iso-8859-1?Q?G=E9rard?= Roudier <groudier@free.fr>
Cc: Kirk Alexander <kirkalx@yahoo.co.nz>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20011214200948.GT1180@suse.de>
In-Reply-To: <20011214041151.91557.qmail@web14904.mail.yahoo.com> <20011214172419.Q1591-100000@gerard>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20011214172419.Q1591-100000@gerard>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Dec 14 2001, Gérard Roudier wrote:
> > I fixed the problem by seeing what the sym
> > driver did i.e. the patch below
> > This may not be right at all, and I haven't had a
> > chance to boot the kernel - but it did build OK.
> 
> The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> reliability and performance.

Gerard,

For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
there _any_ reason to keep the two older ones given your new driver
handles it all?

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S285497AbRLNUk2>; Fri, 14 Dec 2001 15:40:28 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S285498AbRLNUkT>; Fri, 14 Dec 2001 15:40:19 -0500
Received: from ns.virtualhost.dk ([195.184.98.160]:34576 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id <S285497AbRLNUkJ>;
	Fri, 14 Dec 2001 15:40:09 -0500
Date: Fri, 14 Dec 2001 21:34:35 +0100
From: Jens Axboe <axboe@suse.de>
To: Kirk Alexander <kirkalx@yahoo.co.nz>
Cc: groudier@free.fr, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20011214203435.GV1180@suse.de>
In-Reply-To: <20011214041151.91557.qmail@web14904.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011214041151.91557.qmail@web14904.mail.yahoo.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Dec 14 2001, Kirk Alexander wrote:
> [cc'ed to lkml and Gerard Roudier]
> 
> Hi Jens,
> 
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
> 
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver. I fixed the problem by seeing what the sym
> driver did i.e. the patch below 
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.

Missed your original post, it had no subject line. At first view, your
patch looks correct. However, check the ->detect() routing and verify
it's not assuming the lock is held there. That should be the only
pitfall.

Minor nit pick -- since this driver is _in_ the 2.5 tree, there's no way
the #ifdef would not hit. So the way I've been fixing these is to just
always assume latest kernel.

I think this was already fixed though, but at least know you now you did
it right :-)

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S285499AbRLNVBW>; Fri, 14 Dec 2001 16:01:22 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S285501AbRLNVBN>; Fri, 14 Dec 2001 16:01:13 -0500
Received: from mail.libertysurf.net ([213.36.80.91]:23594 "EHLO
	mail.libertysurf.net") by vger.kernel.org with ESMTP
	id <S285499AbRLNVBA> convert rfc822-to-8bit; Fri, 14 Dec 2001 16:01:00 -0500
Date: Fri, 14 Dec 2001 19:05:58 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
X-X-Sender: <groudier@gerard>
To: Jens Axboe <axboe@suse.de>
cc: Kirk Alexander <kirkalx@yahoo.co.nz>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011214200948.GT1180@suse.de>
Message-ID: <20011214183721.H1878-100000@gerard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Fri, 14 Dec 2001, Jens Axboe wrote:

> On Fri, Dec 14 2001, Gérard Roudier wrote:
> > > I fixed the problem by seeing what the sym
> > > driver did i.e. the patch below
> > > This may not be right at all, and I haven't had a
> > > chance to boot the kernel - but it did build OK.
> >
> > The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> > Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> > quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> > it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> > reliability and performance.
>
> Gerard,
>
> For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
> there _any_ reason to keep the two older ones given your new driver
> handles it all?

On my side, there is obviously no reason to keep them in 2.5, as sym-2 is
intended to replace them both. Personnaly I have switched to sym-2 on my
systems since several months.

However, I donnot consider myself as the only owner of these drivers. The
owners are all people that may need symbios chips support under Linux. My
personnal vote, as a user/owner, is to remove them and rely for symbios
chip support on sym-2.

--

Linux stable is a different issue. For this one, I would prefer the old
drivers to remain in place for a longer time. However, I personnaly will
not track bugs on old drivers if either,

- The problem also shows up in sym-2. Then I will try to fix sym-2,
- Or the problem simply doesn't occur in sym-2.

This will apply to problems reported directly by users or by packagers.

By the way, for now, I haven't received any report about sym-2 failing
when sym-1 or ncr succeeds, and my feeling is that this could well be very
unlikely.

But I can make mistakes, me too. :-)

  Gérard.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S284548AbRLNWhT>; Fri, 14 Dec 2001 17:37:19 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S284553AbRLNWhK>; Fri, 14 Dec 2001 17:37:10 -0500
Received: from mailout01.sul.t-online.com ([194.25.134.80]:43400 "EHLO
	mailout01.sul.t-online.com") by vger.kernel.org with ESMTP
	id <S284548AbRLNWgz>; Fri, 14 Dec 2001 17:36:55 -0500
Date: Fri, 14 Dec 2001 23:26:22 +0100 (CET)
From: eduard.epi@t-online.de (Peter Bornemann)
To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
cc: Jens Axboe <axboe@suse.de>, Kirk Alexander <kirkalx@yahoo.co.nz>,
        <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011214183721.H1878-100000@gerard>
Message-ID: <Pine.LNX.4.33.0112142248290.4722-100000@eduard.t-online.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> By the way, for now, I haven't received any report about sym-2 failing
> when sym-1 or ncr succeeds, and my feeling is that this could well be very
> unlikely.
>

Ahemm -- well,
maybe I'm the first one. I have a symbios card, which is recognized by
lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
(formerly NCR) 53c810 (rev 23).

This card goes into an endless loop during parity-checking. So tried to
disable it for the new sym53cxx in modules.conf:
options sym53c8xx mpar:n spar:n
This did not help in this case, however.

There have been so far three ways to solve  this problem:
1. Use the very old ncr53c7,8 or so driver. This is working rather
unreliable for me.
2. Use the ncr53c8xx, which works usually well
3. Use sym53c8xx(old) compiled with parity disabled

Probably there is a way around that, but somebody trying to install Linux
from a SCSI-CDROM with this card for the first time will very likely not
succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
(same driver).
NB Parity checking for me is not really all that important as there is no
hardrive connected to that card. Only CD and scanner.

Peter B

          .         .
          |\_-^^^-_/|
          / (|)_(|) \
         ( === X === )
          \  ._|_.  /
           ^-_   _-^
              °°°


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S278701AbRLNXKc>; Fri, 14 Dec 2001 18:10:32 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S280365AbRLNXKM>; Fri, 14 Dec 2001 18:10:12 -0500
Received: from mail.libertysurf.net ([213.36.80.91]:4903 "EHLO
	mail.libertysurf.net") by vger.kernel.org with ESMTP
	id <S278701AbRLNXKA> convert rfc822-to-8bit; Fri, 14 Dec 2001 18:10:00 -0500
Date: Fri, 14 Dec 2001 21:16:06 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
X-X-Sender: <groudier@gerard>
To: Peter Bornemann <eduard.epi@t-online.de>
cc: Jens Axboe <axboe@suse.de>, Kirk Alexander <kirkalx@yahoo.co.nz>,
        <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0112142248290.4722-100000@eduard.t-online.de>
Message-ID: <20011214210728.K2427-100000@gerard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Fri, 14 Dec 2001, Peter Bornemann wrote:

> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> > By the way, for now, I haven't received any report about sym-2 failing
> > when sym-1 or ncr succeeds, and my feeling is that this could well be very
> > unlikely.
> >
>
> Ahemm -- well,
> maybe I'm the first one. I have a symbios card, which is recognized by
> lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> (formerly NCR) 53c810 (rev 23).
>
> This card goes into an endless loop during parity-checking. So tried to
> disable it for the new sym53cxx in modules.conf:
> options sym53c8xx mpar:n spar:n
> This did not help in this case, however.
>
> There have been so far three ways to solve  this problem:
> 1. Use the very old ncr53c7,8 or so driver. This is working rather
> unreliable for me.
> 2. Use the ncr53c8xx, which works usually well
> 3. Use sym53c8xx(old) compiled with parity disabled
>
> Probably there is a way around that, but somebody trying to install Linux
> from a SCSI-CDROM with this card for the first time will very likely not
> succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
> (same driver).
> NB Parity checking for me is not really all that important as there is no
> hardrive connected to that card. Only CD and scanner.

About what parity sort are you talking about ?
PCI parity ? SCSI parity ?

PCI parity checking is not an option. If it is this one, then your
hardware is simply broken. For such broken hardwares that returns such
spurious PCI parity error early during HBA probing, sym-2 can detect this
and disable PCI parity checking. This has been reported to work well under
FreeBSD. And sym-2 is also supposed to accept the manual disabling, either
by compiled-in option or using the mpar=n boot-up options.

For SCSI parity, which is different matter, both drivers try to cope and
still sym-2 should accept the spar=n boot-up option.

Could you, please,  report me more accurate information.
TIA,
  Gérard.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281024AbRLOA5D>; Fri, 14 Dec 2001 19:57:03 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281059AbRLOA4y>; Fri, 14 Dec 2001 19:56:54 -0500
Received: from ns.ithnet.com ([217.64.64.10]:56072 "HELO heather.ithnet.com")
	by vger.kernel.org with SMTP id <S281024AbRLOA4n>;
	Fri, 14 Dec 2001 19:56:43 -0500
Date: Sat, 15 Dec 2001 01:56:35 +0100
From: Stephan von Krawczynski <skraw@ithnet.com>
To: G?rard Roudier <groudier@free.fr>
Cc: kirkalx@yahoo.co.nz, axboe@suse.de, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-Id: <20011215015635.587b7ac2.skraw@ithnet.com>
In-Reply-To: <20011214172419.Q1591-100000@gerard>
In-Reply-To: <20011214041151.91557.qmail@web14904.mail.yahoo.com>
	<20011214172419.Q1591-100000@gerard>
Organization: ith Kommunikationstechnik GmbH
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
Gérard Roudier <groudier@free.fr> wrote:

> > My system is a clunky old Digital Pentium Pro with a
> > NCR53c810 rev 2 scsi controller, so it can't use the
> > sym driver.
> 
> Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> [...]
> You may let me know if sym53c8xx_2 still works with 810 rev 2.

On my system it does. I have it as a second controller and am using sym-2
without troubles.

Regards,
Stephan



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281059AbRLOBJE>; Fri, 14 Dec 2001 20:09:04 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281217AbRLOBIz>; Fri, 14 Dec 2001 20:08:55 -0500
Received: from mailout01.sul.t-online.com ([194.25.134.80]:39099 "EHLO
	mailout01.sul.t-online.com") by vger.kernel.org with ESMTP
	id <S281059AbRLOBIv>; Fri, 14 Dec 2001 20:08:51 -0500
Date: Sat, 15 Dec 2001 01:54:50 +0100 (CET)
From: eduard.epi@t-online.de (Peter Bornemann)
To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
cc: Peter Bornemann <eduard.epi@t-online.de>, Jens Axboe <axboe@suse.de>,
        Kirk Alexander <kirkalx@yahoo.co.nz>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011214210728.K2427-100000@gerard>
Message-ID: <Pine.LNX.4.33.0112150136390.5849-100000@eduard.t-online.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:

>
>
> On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > Ahemm -- well,
> > maybe I'm the first one. I have a symbios card, which is recognized by
> > lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > (formerly NCR) 53c810 (rev 23).
> Could you, please,  report me more accurate information.
> TIA,
>

Well, it seems I made my intention not very clear: I do not want You to
fix something in the driver, I just wanted from You to leave the old
ncr-driver in the kernel, just for the situation of a first install. I
think no newbie with little knowledge will be able to install Linux (or,
maybe, FreeBSD), when he happens to own such an controller. First, he
won't be able to read very much on the screen, for the loop runs much too
fast and second, he will not understand when he reads something about a
sym53c8xx. Exactly for this case I think the old driver should be left in.
If You want, You can tell him "Attention! Use of this driver deprecated.
Contact Your support." or whatever seems appropriate. It is just about the
first step to linuxland :-)

Hope I managed to make myself clear tris time

Peter B



          .         .
          |\_-^^^-_/|
          / (|)_(|) \
         ( === X === )
          \  ._|_.  /
           ^-_   _-^
              °°°


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S282064AbRLOJyH>; Sat, 15 Dec 2001 04:54:07 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S282067AbRLOJx6>; Sat, 15 Dec 2001 04:53:58 -0500
Received: from mail.libertysurf.net ([213.36.80.91]:31008 "EHLO
	mail.libertysurf.net") by vger.kernel.org with ESMTP
	id <S282064AbRLOJxr> convert rfc822-to-8bit; Sat, 15 Dec 2001 04:53:47 -0500
Date: Sat, 15 Dec 2001 07:57:28 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
X-X-Sender: <groudier@gerard>
To: Peter Bornemann <eduard.epi@t-online.de>
cc: Jens Axboe <axboe@suse.de>, Kirk Alexander <kirkalx@yahoo.co.nz>,
        <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0112150136390.5849-100000@eduard.t-online.de>
Message-ID: <20011215073941.J645-100000@gerard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Sat, 15 Dec 2001, Peter Bornemann wrote:

> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
>
> >
> >
> > On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > > Ahemm -- well,
> > > maybe I'm the first one. I have a symbios card, which is recognized by
> > > lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > > (formerly NCR) 53c810 (rev 23).
> > Could you, please,  report me more accurate information.
> > TIA,
> >
>
> Well, it seems I made my intention not very clear: I do not want You to
> fix something in the driver, I just wanted from You to leave the old
> ncr-driver in the kernel, just for the situation of a first install. I
> think no newbie with little knowledge will be able to install Linux (or,
> maybe, FreeBSD), when he happens to own such an controller. First, he
> won't be able to read very much on the screen, for the loop runs much too
> fast and second, he will not understand when he reads something about a
> sym53c8xx. Exactly for this case I think the old driver should be left in.
> If You want, You can tell him "Attention! Use of this driver deprecated.
> Contact Your support." or whatever seems appropriate. It is just about the
> first step to linuxland :-)
>
> Hope I managed to make myself clear tris time

I have limited time and am very bad in politics. I do prefer to have to
deal with accurate technical issues. My english is also limited to this
field.

You would have been clear if you had reported:

1) Which of the mpar= spar= and/or corresponding compiled-in options made
   your broken hardware works (with high risks of silent corruption).

2) If using the corresponding compiled-in option worked with sym-2.

3) Optionnaly, relevant messages printed by sym-2, even taken by hand,
   when the problem occurs.

+ any other pertinent information I cannot guess about you thought can
  help.

About FreeBSD, the only information I have is that the (sad) work-around I
implemented and that is incorporated in sym-2 _did_ work around the
problem of PCI parity error for people that did report results.

Could you be clear, as expected by technical group of discussions, please.

  Gérard.

PS: The ncr53c8xx may just work since it does trust POST software to
    enable PCI parity checking bit in PCI config space. But it seems that
    most POST shits donnot do so, leaving systems with the risk of silent
    data corruption in contradiction with either PCI specifications and user
    expectation.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S282118AbRLOJx5>; Sat, 15 Dec 2001 04:53:57 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S282067AbRLOJxi>; Sat, 15 Dec 2001 04:53:38 -0500
Received: from mail.libertysurf.net ([213.36.80.91]:18474 "EHLO
	mail.libertysurf.net") by vger.kernel.org with ESMTP
	id <S282064AbRLOJx1> convert rfc822-to-8bit; Sat, 15 Dec 2001 04:53:27 -0500
Date: Sat, 15 Dec 2001 07:59:36 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
X-X-Sender: <groudier@gerard>
To: Stephan von Krawczynski <skraw@ithnet.com>
cc: <kirkalx@yahoo.co.nz>, <axboe@suse.de>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011215015635.587b7ac2.skraw@ithnet.com>
Message-ID: <20011215075913.A677-100000@gerard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Sat, 15 Dec 2001, Stephan von Krawczynski wrote:

> On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
> Gérard Roudier <groudier@free.fr> wrote:
>
> > > My system is a clunky old Digital Pentium Pro with a
> > > NCR53c810 rev 2 scsi controller, so it can't use the
> > > sym driver.
> >
> > Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> > [...]
> > You may let me know if sym53c8xx_2 still works with 810 rev 2.
>
> On my system it does. I have it as a second controller and am using sym-2
> without troubles.

Thanks for your report.

  Gérard.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281165AbRLQQWj>; Mon, 17 Dec 2001 11:22:39 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281214AbRLQQWa>; Mon, 17 Dec 2001 11:22:30 -0500
Received: from ns.suse.de ([213.95.15.193]:15885 "HELO Cantor.suse.de")
	by vger.kernel.org with SMTP id <S281165AbRLQQWO> convert rfc822-to-8bit;
	Mon, 17 Dec 2001 11:22:14 -0500
Date: Mon, 17 Dec 2001 17:22:14 +0100 (CET)
From: Dave Jones <davej@suse.de>
To: Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <sebastian.droege@gmx.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011217170740.74a1cb95.sebastian.droege@gmx.de>
Message-ID: <Pine.LNX.4.33.0112171717010.28670-100000@Appserv.suse.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> Attached you find my .config, lspci -vvv and dmesg output
> I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)

Thanks. Right now getting 2.4 into a better shape is more
important than fixing 2.5, so if you find any problems repeatable
in 2.4.17rc1, Marcelo really needs to know about it.

The only USB changes in my tree are __devinit_p changes, which
really shouldn't be causing a problem, but there could be some
other unrelated-to-usb patch which is causing this..

2.4 info would be appreciated.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281214AbRLQQuV>; Mon, 17 Dec 2001 11:50:21 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281255AbRLQQuL>; Mon, 17 Dec 2001 11:50:11 -0500
Received: from pop.gmx.net ([213.165.64.20]:59224 "HELO mail.gmx.net")
	by vger.kernel.org with SMTP id <S281214AbRLQQuA>;
	Mon, 17 Dec 2001 11:50:00 -0500
Date: Mon, 17 Dec 2001 17:52:06 +0100
From: Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <sebastian.droege@gmx.de>
To: Dave Jones <davej@suse.de>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: your mail
Message-Id: <20011217175206.193d02e0.sebastian.droege@gmx.de>
In-Reply-To: <Pine.LNX.4.33.0112171717010.28670-100000@Appserv.suse.de>
In-Reply-To: <20011217170740.74a1cb95.sebastian.droege@gmx.de>
	<Pine.LNX.4.33.0112171717010.28670-100000@Appserv.suse.de>
X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="=.Fd.uRJK)t83+S4"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

--=.Fd.uRJK)t83+S4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Ok...
2.4.16-2.4.17-rc1 works perfectly
2.5.0-2.5.1 works perfectly
Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
All have the same .config
If you need some more information feel free to ask me ;)

Bye

PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
INIT can't send the TERM signal to all processes...
Nothing happens... no error message no nothing
SysRQ works
I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
Does anyone have informations about it?

On Mon, 17 Dec 2001 17:22:14 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > Attached you find my .config, lspci -vvv and dmesg output
> > I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)
> 
> Thanks. Right now getting 2.4 into a better shape is more
> important than fixing 2.5, so if you find any problems repeatable
> in 2.4.17rc1, Marcelo really needs to know about it.
> 
> The only USB changes in my tree are __devinit_p changes, which
> really shouldn't be causing a problem, but there could be some
> other unrelated-to-usb patch which is causing this..
> 
> 2.4 info would be appreciated.
> 
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--=.Fd.uRJK)t83+S4
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE8HiK8vIHrJes3kVIRAvdIAJsE4AK9YCjxWEHoFzM7l3uTFAj8qACgoOvT
vyt1nn/MuV/3AOM/WxDIZMY=
=+S85
-----END PGP SIGNATURE-----

--=.Fd.uRJK)t83+S4--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281458AbRLQQ4B>; Mon, 17 Dec 2001 11:56:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281483AbRLQQzv>; Mon, 17 Dec 2001 11:55:51 -0500
Received: from garrincha.netbank.com.br ([200.203.199.88]:20497 "HELO
	netbank.com.br") by vger.kernel.org with SMTP id <S281458AbRLQQzr>;
	Mon, 17 Dec 2001 11:55:47 -0500
Date: Mon, 17 Dec 2001 14:55:01 -0200
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: Sebastian@conectiva.com.br,
        =?iso-8859-1?Q?Dr=F6ge_=3Csebastian=2Edroege=40gmx=2Ede=3E?=@conectiva.com.br
Cc: Dave Jones <davej@suse.de>, linux-kernel@vger.kernel.org,
        torvalds@transmeta.com
Subject: Re: your mail
Message-ID: <20011217145501.B1196@conectiva.com.br>
Mail-Followup-To: Arnaldo Carvalho de Melo <acme@conectiva.com.br>,
	Sebastian@conectiva.com.br,
	=?iso-8859-1?Q?Dr=F6ge_=3Csebastian=2Edroege?=@conectiva.com.br,
	=?iso-8859-1?B?QGdteC5kZT4=?=@conectiva.com.br,
	Dave Jones <davej@suse.de>, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com
In-Reply-To: <20011217170740.74a1cb95.sebastian.droege@gmx.de> <Pine.LNX.4.33.0112171717010.28670-100000@Appserv.suse.de> <20011217175206.193d02e0.sebastian.droege@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20011217175206.193d02e0.sebastian.droege@gmx.de>
User-Agent: Mutt/1.3.23i
X-Url: http://advogato.org/person/acme
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Em Mon, Dec 17, 2001 at 05:52:06PM +0100, Sebastian Dröge escreveu:
> PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
> INIT can't send the TERM signal to all processes...

see the kill(-1,sig) thread...

> Nothing happens... no error message no nothing
> SysRQ works
> I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
> PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
> Does anyone have informations about it?

Advanced Programmable Interrupt Controller, found in SMP machines and in
some UP ones, for UP its shouldn't be enabled in most cases.

- Arnaldo

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281663AbRLQRV4>; Mon, 17 Dec 2001 12:21:56 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281678AbRLQRVq>; Mon, 17 Dec 2001 12:21:46 -0500
Received: from mail.gmx.net ([213.165.64.20]:20490 "HELO mail.gmx.net")
	by vger.kernel.org with SMTP id <S281663AbRLQRVc>;
	Mon, 17 Dec 2001 12:21:32 -0500
Date: Mon, 17 Dec 2001 18:23:43 +0100
From: Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <sebastian.droege@gmx.de>
To: Dave Jones <davej@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-Id: <20011217182343.7aea2048.sebastian.droege@gmx.de>
In-Reply-To: <Pine.LNX.4.33.0112171755060.28670-100000@Appserv.suse.de>
In-Reply-To: <20011217175206.193d02e0.sebastian.droege@gmx.de>
	<Pine.LNX.4.33.0112171755060.28670-100000@Appserv.suse.de>
X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="=.QmtTog?6kiEPJ9"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

--=.QmtTog?6kiEPJ9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Thanks
This does work
What do you think was exactly the problem?

Bye

On Mon, 17 Dec 2001 17:57:01 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > 2.4.16-2.4.17-rc1 works perfectly
> > 2.5.0-2.5.1 works perfectly
> > Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
> > All have the same .config
> > If you need some more information feel free to ask me ;)
> 
> Ok, can you try backing out this patch.. (just patch as normal but with -R)
> http://www.codemonkey.org.uk/patches/2.5/small-bits/early-cpuinit-1.diff
> 
> regards,
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 

--=.QmtTog?6kiEPJ9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE8HiohvIHrJes3kVIRAtPVAKCscabhKjpmPSyZccFYDwvr3rSmhgCgpNfu
nLzkwv2BjBvxQL43xOFwVsk=
=jWZX
-----END PGP SIGNATURE-----

--=.QmtTog?6kiEPJ9--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S281678AbRLQR0G>; Mon, 17 Dec 2001 12:26:06 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S281719AbRLQRZ4>; Mon, 17 Dec 2001 12:25:56 -0500
Received: from ns.suse.de ([213.95.15.193]:50436 "HELO Cantor.suse.de")
	by vger.kernel.org with SMTP id <S281678AbRLQRZs> convert rfc822-to-8bit;
	Mon, 17 Dec 2001 12:25:48 -0500
Date: Mon, 17 Dec 2001 18:25:37 +0100 (CET)
From: Dave Jones <davej@suse.de>
To: =?ISO-8859-1?Q?Sebastian_Dr=F6ge?= <sebastian.droege@gmx.de>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011217182343.7aea2048.sebastian.droege@gmx.de>
Message-ID: <Pine.LNX.4.33.0112171822250.28670-100000@Appserv.suse.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> Thanks
> This does work

Great, now can you edit the patch to remove the ioapic.c hunk,
reapply, and see if that works..

> What do you think was exactly the problem?

looks like I dorked the apic init...
I'll back that bit out for -dj2, until I've given
it a bit more work.

regards,
Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S282099AbRLQSm2>; Mon, 17 Dec 2001 13:42:28 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S282092AbRLQSmW>; Mon, 17 Dec 2001 13:42:22 -0500
Received: from pop.gmx.de ([213.165.64.20]:62167 "HELO mail.gmx.net")
	by vger.kernel.org with SMTP id <S281932AbRLQSko>;
	Mon, 17 Dec 2001 13:40:44 -0500
Date: Mon, 17 Dec 2001 19:42:55 +0100
From: Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <sebastian.droege@gmx.de>
To: Dave Jones <davej@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-Id: <20011217194255.1267baa7.sebastian.droege@gmx.de>
In-Reply-To: <Pine.LNX.4.33.0112171822250.28670-100000@Appserv.suse.de>
In-Reply-To: <20011217182343.7aea2048.sebastian.droege@gmx.de>
	<Pine.LNX.4.33.0112171822250.28670-100000@Appserv.suse.de>
X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="=.fAe.)5nqcaTw+."
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

--=.fAe.)5nqcaTw+.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hmm...
I don't see anything about ioapic.c in the patch...
So I removed the apic.c hunk
I think you meant that ;)
Anyway this doesn't solve the problem :(

Bye

On Mon, 17 Dec 2001 18:25:37 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > Thanks
> > This does work
> 
> Great, now can you edit the patch to remove the ioapic.c hunk,
> reapply, and see if that works..
> 
> > What do you think was exactly the problem?
> 
> looks like I dorked the apic init...
> I'll back that bit out for -dj2, until I've given
> it a bit more work.
> 
> regards,
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 

--=.fAe.)5nqcaTw+.
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE8HjyxvIHrJes3kVIRAibXAJ4l93Y3Jjf0nJzqlmdtE9CSOwWGCgCgk7+o
+/IlbOIe67unU50wZ1dAQik=
=dvQ4
-----END PGP SIGNATURE-----

--=.fAe.)5nqcaTw+.--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S282178AbRLQSpK>; Mon, 17 Dec 2001 13:45:10 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S282176AbRLQSov>; Mon, 17 Dec 2001 13:44:51 -0500
Received: from ns.suse.de ([213.95.15.193]:63501 "HELO Cantor.suse.de")
	by vger.kernel.org with SMTP id <S282092AbRLQSnx> convert rfc822-to-8bit;
	Mon, 17 Dec 2001 13:43:53 -0500
Date: Mon, 17 Dec 2001 19:43:52 +0100 (CET)
From: Dave Jones <davej@suse.de>
To: =?ISO-8859-1?Q?Sebastian_Dr=F6ge?= <sebastian.droege@gmx.de>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20011217194255.1267baa7.sebastian.droege@gmx.de>
Message-ID: <Pine.LNX.4.33.0112171943030.28670-100000@Appserv.suse.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> So I removed the apic.c hunk
> I think you meant that ;)

*nod*

> Anyway this doesn't solve the problem :(

Ok, this isn't urgent anyway, I'll get around to cleaning that
up later. Thanks for your help tracing this.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S283265AbRLRAev>; Mon, 17 Dec 2001 19:34:51 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S283269AbRLRAel>; Mon, 17 Dec 2001 19:34:41 -0500
Received: from web14909.mail.yahoo.com ([216.136.225.61]:36616 "HELO
	web14909.mail.yahoo.com") by vger.kernel.org with SMTP
	id <S283267AbRLRAeW>; Mon, 17 Dec 2001 19:34:22 -0500
Message-ID: <20011218003418.468.qmail@web14909.mail.yahoo.com>
Date: Tue, 18 Dec 2001 13:34:18 +1300 (NZDT)
From: =?iso-8859-1?q?Kirk=20Alexander?= <kirkalx@yahoo.co.nz>
Subject: Re: your mail
To: =?ISO-8859-1?Q? "G=E9rard=5FRoudier" ?= <groudier@free.fr>
Cc: Jens Axboe <axboe@suse.de>, linux-kernel@vger.kernel.org
In-Reply-To: <20011214172419.Q1591-100000@gerard>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

 --- Gérard_Roudier <groudier@free.fr> wrote: > 
> 
[snip]
> 
> You may let me know if sym53c8xx_2 still works with 810 rev 2.
> 



I tried the sym53c8xx_2 driver, put a fair load on the system (lots of sync'ing
and swapping) and didn't seem to have any trouble.

Cheers,
 Kirk Alexander



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S286421AbRL0SMI>; Thu, 27 Dec 2001 13:12:08 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S286415AbRL0SLt>; Thu, 27 Dec 2001 13:11:49 -0500
Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253]:59398
	"EHLO master.linux-ide.org") by vger.kernel.org with ESMTP
	id <S286421AbRL0SLi>; Thu, 27 Dec 2001 13:11:38 -0500
Date: Thu, 27 Dec 2001 10:09:41 -0800 (PST)
From: Andre Hedrick <andre@linux-ide.org>
To: Linus Torvalds <torvalds@transmeta.com>
cc: Keith Owens <kaos@ocs.com.au>, kbuild-devel@lists.sourceforge.net,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0112062109400.7866-100000@penguin.transmeta.com>
Message-ID: <Pine.LNX.4.10.10112271008350.24428-100000@master.linux-ide.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 6 Dec 2001, Linus Torvalds wrote:

> 
> On Fri, 7 Dec 2001, Keith Owens wrote:
> >
> > Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.
> 
> We're getting the block IO layer in shape first, the time has not come for
> _anything_ else before that.
> 
> 		Linus

Lots of luck ... please pass your crack pipe arounds so the rest of us
idiots can see your vision or lack of ...

Regards,

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S286482AbRL0S6i>; Thu, 27 Dec 2001 13:58:38 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S286477AbRL0S63>; Thu, 27 Dec 2001 13:58:29 -0500
Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:36872 "EHLO
	neon-gw.transmeta.com") by vger.kernel.org with ESMTP
	id <S286482AbRL0S6U>; Thu, 27 Dec 2001 13:58:20 -0500
Date: Thu, 27 Dec 2001 10:55:59 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
To: Andre Hedrick <andre@linux-ide.org>
cc: Keith Owens <kaos@ocs.com.au>, <kbuild-devel@lists.sourceforge.net>,
        <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.10.10112271008350.24428-100000@master.linux-ide.org>
Message-ID: <Pine.LNX.4.33.0112271025590.1052-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


On Thu, 27 Dec 2001, Andre Hedrick wrote:
>
> Lots of luck ... please pass your crack pipe arounds so the rest of us
> idiots can see your vision or lack of ...

Heh. I think I must have passed it on to you long ago, and you never gave
it back, you sneaky bastard ;)

The vision, btw, is to get the request layer in good enough shape that we
can dispense with the mid-layer approaches of SCSI/IDE, and block devices
turn into _just_ device drivers.

For example, ide-scsi is heading for that big scrap-yard in the sky: it's
not the SCSI layer that handles special ioctl requests any more, because
the upper layers are going to be flexible enough that you can just pass
the requests down the regular pipe.

(Right now you can see this in block_ioctl.c - while only a few of the
ioctl's have been converted, you get the idea. I'm actually surprised that
nobody seems to have commented on that part).

The final end result of this (I sincerely hope) is that we can get rid of
some of the couplings that we've had in the block layer. ide-scsi is just
the most obvious strange coupling - things like "sg.c" in general are
rather horrible. There's very little _SCSI_ in sg.c - it's really about
sending commands down to the block devices.

The reason I want to get rid of the couplings is that they end up being
big anchors holding down development: you can create a clean driver that
isn't dependent on the SCSI layer overheads (and people do, for things
like DAC etc), but when you do that you lose _all_ of the support
infrastructure, not just the bloat. Which is sad.

(And which is why things like ide-scsi exist - IDE didn't really want to
be a SCSI driver, but people _did_ want to be able to use some of the
generic support routines that the SCSI layer offers. You couldn't just
cherry-pick the parts you wanted).

The other part of the bio rewrite has been to get rid of another coupling:
the coupling between "struct buffer_head" (which is used for a limited
kind of memory management by a number of filesystems) and the act of
actually just doing IO.

I used to think that we could just relegate "struct buffer_head" to _be_
the IO entity, but it turns out to be much easier to just split off the IO
part, which is why you now have a separate "bio" structure for the block
IO part, and the buffer_head stuff uses that to get the work done.

Andre, I know that you're worried about the low-level drivers, but:

 - I've long since noticed that we cannot communicate, which is why Jens
   is the block level driver person. You'll have to live with it.

 - I personally don't think you _can_ make a good driver without having
   reasonable interfaces, and we didn't have them.

   For example, the network drivers have improved a lot and do not have
   _nearly_ the amount of problems block drivers have. That's obviously
   partly just because it is a simpler problem, but because it was simpler
   it was also possible to change them. The infrastructure changes in the
   networking during 2.3.x really did help drivers.

And note that the "Jens" and "communication" part is important. If you
have patches, please talk to Jens, tell him what the issues, are, and I
know I can communicate with him.

			Linus



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S286541AbRL0TpZ>; Thu, 27 Dec 2001 14:45:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S286556AbRL0TpO>; Thu, 27 Dec 2001 14:45:14 -0500
Received: from vasquez.zip.com.au ([203.12.97.41]:37900 "EHLO
	vasquez.zip.com.au") by vger.kernel.org with ESMTP
	id <S286541AbRL0TpB>; Thu, 27 Dec 2001 14:45:01 -0500
Message-ID: <3C2B7981.EDCBEFA@zip.com.au>
Date: Thu, 27 Dec 2001 11:41:53 -0800
From: Andrew Morton <akpm@zip.com.au>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-pre8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linus Torvalds <torvalds@transmeta.com>
CC: Andre Hedrick <andre@linux-ide.org>, Keith Owens <kaos@ocs.com.au>,
        kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.10.10112271008350.24428-100000@master.linux-ide.org> <Pine.LNX.4.33.0112271025590.1052-100000@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Linus Torvalds wrote:
> 
> The other part of the bio rewrite has been to get rid of another coupling:
> the coupling between "struct buffer_head" (which is used for a limited
> kind of memory management by a number of filesystems) and the act of
> actually just doing IO.
> 
> I used to think that we could just relegate "struct buffer_head" to _be_
> the IO entity, but it turns out to be much easier to just split off the IO
> part, which is why you now have a separate "bio" structure for the block
> IO part, and the buffer_head stuff uses that to get the work done.
> 

So... would it be correct to say that there won't be any large
changes to the buffer_head concept in 2.5?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S283771AbRL1W0D>; Fri, 28 Dec 2001 17:26:03 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S283724AbRL1WZn>; Fri, 28 Dec 2001 17:25:43 -0500
Received: from [195.63.194.11] ([195.63.194.11]:37899 "EHLO
	mail.stock-world.de") by vger.kernel.org with ESMTP
	id <S282805AbRL1WZb>; Fri, 28 Dec 2001 17:25:31 -0500
Message-ID: <3C2CEEB5.1080801@evision-ventures.com>
Date: Fri, 28 Dec 2001 23:14:13 +0100
From: Martin Dalecki <dalecki@evision-ventures.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us, pl
MIME-Version: 1.0
To: Linus Torvalds <torvalds@transmeta.com>
CC: Andre Hedrick <andre@linux-ide.org>, Keith Owens <kaos@ocs.com.au>,
        kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0112271025590.1052-100000@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Linus Torvalds wrote:

>(Right now you can see this in block_ioctl.c - while only a few of the
>ioctl's have been converted, you get the idea. I'm actually surprised that
>nobody seems to have commented on that part).
>

That was just too obvious, at least for me... However I don't see why 
you just don't start killing of constructs like:

swtch  (ioctrl)

    BLASH:
BLAHHH:
 BLASHH:
 BLAASS:
     BLAH:
    default:
            return -ENOVAL;
}

There are ton' s of them out there in the block drivers..


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S288959AbSAISSg>; Wed, 9 Jan 2002 13:18:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S288958AbSAISSW>; Wed, 9 Jan 2002 13:18:22 -0500
Received: from ns.virtualhost.dk ([195.184.98.160]:37640 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id <S288957AbSAISRs>;
	Wed, 9 Jan 2002 13:17:48 -0500
Date: Wed, 9 Jan 2002 19:17:36 +0100
From: Jens Axboe <axboe@suse.de>
To: Michael Zhu <mylinuxk@yahoo.ca>
Cc: root@chaos.analogic.com, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020109191736.L19814@suse.de>
In-Reply-To: <20020109174926.23012.qmail@web14902.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020109174926.23012.qmail@web14902.mail.yahoo.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 09 2002, Michael Zhu wrote:
> > 
> > This may be a troll. How would you boot? Who
> decrypts during the
> > boot?
> > 
> 
> You mean that the loop device couldn't en/decrypt the
> whole data on the disk? That mean the loop device
> could implement the block level en/decryption.

Please, read up on the loop crypto stuff off-list. Most of these
questions are very FAQ. You can loop crypto a whole disk or partition of
you want.

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S290309AbSA3TAt>; Wed, 30 Jan 2002 14:00:49 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S290351AbSA3S7a>; Wed, 30 Jan 2002 13:59:30 -0500
Received: from [195.163.186.27] ([195.163.186.27]:32967 "EHLO zmailer.org")
	by vger.kernel.org with ESMTP id <S290347AbSA3S5o>;
	Wed, 30 Jan 2002 13:57:44 -0500
Date: Wed, 30 Jan 2002 20:57:30 +0200
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Nickolaos Fotopoulos <nick@rsvpusa.com>
Cc: "Linux kernel list (E-mail)" <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20020130205730.C5808@mea-ext.zmailer.org>
In-Reply-To: <21B5EAC6675ED411B62500105A9C006018D42A@XCHANGE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21B5EAC6675ED411B62500105A9C006018D42A@XCHANGE>; from nick@rsvpusa.com on Wed, Jan 30, 2002 at 01:21:17PM -0500
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 30, 2002 at 01:21:17PM -0500, Nickolaos Fotopoulos wrote:
> I'm new to this list.  Does it get spammed often, like this guy
> (grumph@pakistanmail.com) is doing?  It is allready becoming quite anouying!

  I already asked about the phenomena, and the guy(?) replied that
  he won't use that system anymore as it is doing those repeated
  sends all by itself.

> This is by far the busiest list I have ever subscribed to, and there does
> not seem to be any sort of spam blocker working here.  I thought Majodomo
> had stuff like this built in?  If not maybe a list moderator could address
> this.

  http://vger.kernel.org/majordomo-info.html

  Trust me, there is HEAVY filtering.
  Still some spams do get thru.

> 				Nick Fotopoulos

/Matti Aarnio

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S290824AbSAaBx6>; Wed, 30 Jan 2002 20:53:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S290826AbSAaBxs>; Wed, 30 Jan 2002 20:53:48 -0500
Received: from ns1.intercarve.net ([216.254.127.221]:2444 "HELO
	ceramicfrog.intercarve.net") by vger.kernel.org with SMTP
	id <S290824AbSAaBxn>; Wed, 30 Jan 2002 20:53:43 -0500
Date: Wed, 30 Jan 2002 20:50:58 -0500 (EST)
From: "Drew P. Vogel" <dvogel@intercarve.net>
To: Nickolaos Fotopoulos <nick@rsvpusa.com>
Cc: "Linux kernel list (E-mail)" <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <21B5EAC6675ED411B62500105A9C006018D42A@XCHANGE>
Message-ID: <Pine.LNX.4.33.0201302050190.11522-100000@northface.intercarve.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Personally, when I'm getting a few hundred emails per day, I don't even
notice the 5% spam.

--Drew Vogel

On Wed, 30 Jan 2002, Nickolaos Fotopoulos wrote:

>I'm new to this list.  Does it get spammed often, like this guy
>(grumph@pakistanmail.com) is doing?  It is allready becoming quite anouying!
>This is by far the busiest list I have ever subscribed to, and there does
>not seem to be any sort of spam blocker working here.  I thought Majodomo
>had stuff like this built in?  If not maybe a list moderator could address
>this.
>				Nick Fotopoulos
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293189AbSBYB7U>; Sun, 24 Feb 2002 20:59:20 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293257AbSBYB7J>; Sun, 24 Feb 2002 20:59:09 -0500
Received: from leibniz.math.psu.edu ([146.186.130.2]:44785 "EHLO math.psu.edu")
	by vger.kernel.org with ESMTP id <S293189AbSBYB6y>;
	Sun, 24 Feb 2002 20:58:54 -0500
Date: Sun, 24 Feb 2002 20:58:49 -0500 (EST)
From: Alexander Viro <viro@math.psu.edu>
To: Rusty Russell <rusty@rustcorp.com.au>
cc: Linus Torvalds <torvalds@transmeta.com>, mingo@elte.hu,
        Matthew Kirkwood <matthew@hairy.beasts.org>,
        Benjamin LaHaise <bcrl@redhat.com>, David Axmark <david@mysql.com>,
        William Lee Irwin III <wli@holomorphy.com>,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <E16fA92-0007en-00@wagner.rustcorp.com.au>
Message-ID: <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Mon, 25 Feb 2002, Rusty Russell wrote:

> > Note that getting a file descriptor is really quite useful - it means that
> > you can pass the file descriptor around through unix domain sockets, for
> > example, and allow sharing of the semaphore across unrelated processes
> > that way.
> 
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you

Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
struct file *.  As soon as datagram is sent, descriptors are resolved and
after that point descriptor table of sender (or, for that matter, survival
of sender) doesn't matter.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293301AbSBYCto>; Sun, 24 Feb 2002 21:49:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S291613AbSBYCte>; Sun, 24 Feb 2002 21:49:34 -0500
Received: from sydney1.au.ibm.com ([202.135.142.193]:4873 "EHLO
	haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP
	id <S293301AbSBYCtX>; Sun, 24 Feb 2002 21:49:23 -0500
From: Rusty Russell <rusty@rustcorp.com.au>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>, mingo@elte.hu,
        Matthew Kirkwood <matthew@hairy.beasts.org>,
        Benjamin LaHaise <bcrl@redhat.com>, David Axmark <david@mysql.com>,
        William Lee Irwin III <wli@holomorphy.com>,
        linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-Reply-To: Your message of "Sun, 24 Feb 2002 20:58:49 CDT."
             <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> 
Date: Mon, 25 Feb 2002 13:14:29 +1100
Message-Id: <E16fAer-0000vA-00@wagner.rustcorp.com.au>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
e:
> 
> 
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > someone to pick it up, and they vanish when you exit.  Secondly, you
> 
> Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> struct file *.  As soon as datagram is sent, descriptors are resolved and
> after that point descriptor table of sender (or, for that matter, survival
> of sender) doesn't matter.

Please explain how I leave a fd somewhere for other processes to grab
it.  

And then please explain how they get the fd after I've exited.

Al, you are one of the most unpleasant people to deal with on this
list.  This is *not* an honor, and I beg you to consider a different
approach in future correspondence.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293302AbSBYDQL>; Sun, 24 Feb 2002 22:16:11 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S291619AbSBYDQB>; Sun, 24 Feb 2002 22:16:01 -0500
Received: from x35.xmailserver.org ([208.129.208.51]:24068 "EHLO
	x35.xmailserver.org") by vger.kernel.org with ESMTP
	id <S293302AbSBYDPv>; Sun, 24 Feb 2002 22:15:51 -0500
X-AuthUser: davidel@xmailserver.org
Date: Sun, 24 Feb 2002 19:18:23 -0800 (PST)
From: Davide Libenzi <davidel@xmailserver.org>
X-X-Sender: davide@blue1.dev.mcafeelabs.com
To: Rusty Russell <rusty@rustcorp.com.au>
cc: Alexander Viro <viro@math.psu.edu>,
        Linus Torvalds <torvalds@transmeta.com>, <mingo@elte.hu>,
        Matthew Kirkwood <matthew@hairy.beasts.org>,
        Benjamin LaHaise <bcrl@redhat.com>, David Axmark <david@mysql.com>,
        William Lee Irwin III <wli@holomorphy.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: your mail 
In-Reply-To: <E16fAer-0000vA-00@wagner.rustcorp.com.au>
Message-ID: <Pine.LNX.4.44.0202241906230.7321-100000@blue1.dev.mcafeelabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 25 Feb 2002, Rusty Russell wrote:

> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> >
> >
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit.  Secondly, you
> >
> > Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> > struct file *.  As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
>
> Please explain how I leave a fd somewhere for other processes to grab
> it.
>
> And then please explain how they get the fd after I've exited.
>
> Al, you are one of the most unpleasant people to deal with on this
> list.  This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.

Actually, this is one of Al's nicest posts :-)
You obviously can't share fd# but you can share file*
I don't know how you're going to have these semaphores 'externally visible',
if with numbers like IPC sems or if with pathnames like unix sockets ( or
something else ). But you can have internally a number/path/else -> file*
mapping and when a task attaches the sem you map the file* onto an fd# in
the task's file table. If you keep this mapping persistent ( until
explicit deletion ) the file* remain alive event with zero attached
processes. I think it's this what Al was trying to say.




- Davide




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293314AbSBYEDh>; Sun, 24 Feb 2002 23:03:37 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293315AbSBYED2>; Sun, 24 Feb 2002 23:03:28 -0500
Received: from leibniz.math.psu.edu ([146.186.130.2]:50129 "EHLO math.psu.edu")
	by vger.kernel.org with ESMTP id <S293314AbSBYEDN>;
	Sun, 24 Feb 2002 23:03:13 -0500
Date: Sun, 24 Feb 2002 23:02:58 -0500 (EST)
From: Alexander Viro <viro@math.psu.edu>
To: Rusty Russell <rusty@rustcorp.com.au>
cc: Linus Torvalds <torvalds@transmeta.com>, mingo@elte.hu,
        Matthew Kirkwood <matthew@hairy.beasts.org>,
        Benjamin LaHaise <bcrl@redhat.com>, David Axmark <david@mysql.com>,
        William Lee Irwin III <wli@holomorphy.com>,
        linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-Reply-To: <E16fAer-0000vA-00@wagner.rustcorp.com.au>
Message-ID: <Pine.GSO.4.21.0202242230370.1549-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Mon, 25 Feb 2002, Rusty Russell wrote:

> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> > 
> > 
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit.  Secondly, you
> > 
> > Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> > struct file *.  As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
> 
> Please explain how I leave a fd somewhere for other processes to grab
> it.  
> 
> And then please explain how they get the fd after I've exited.
> 
> Al, you are one of the most unpleasant people to deal with on this
> list.  This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.

Honour or not, in this case your complaint is hardly deserved.  To
compress the above a bit:

you: <false statement>
me: RTFS.  <short description of the reasons why statement is wrong; further
details could be obtained by reading TFS>

As for your question, SCM_RIGHTS datagram can easily outlive the sending
process.  You will need a helper process (either per-meeting point or
system-wide) to avoid GC killing the thing, but that's it.

Writing such helper is left as an exercise to reader - it _is_ trivial.
To put fd(s):
	connect to (name of AF_UNIX socket)
	sendmsg to it; no OOB data, one byte of data (non-0)
	form an SCM_RIGHTS datagram with fds in question
	sendmsg it to the same socket.
	close the socket
In helper:
	listen on (name)
repeat:
	accept connection
	read one byte
	if it's non-zero
		put fd of connection into a list
		goto repeat
	else
		take first fd from list
		form an SCM_RIGHTS datagram with that fd
		send it into the new connection
		close fd
		close connection
		goto repeat
To get fd(s):
	connect ....
	sendmsg .................................... (0)
	recvmsg and pick fd from the message
	close connection
	recvmsg from fd and pick the set of fds from the message
	close fd

End of story.  In real-life situation you will want to throttle in helper,
etc., but in any case main loop is ~20 lines of code.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293402AbSBYNDe>; Mon, 25 Feb 2002 08:03:34 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293403AbSBYNDc>; Mon, 25 Feb 2002 08:03:32 -0500
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:30222 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S293402AbSBYNDE>; Mon, 25 Feb 2002 08:03:04 -0500
Subject: Re: your mail
To: rusty@rustcorp.com.au (Rusty Russell)
Date: Mon, 25 Feb 2002 13:16:09 +0000 (GMT)
Cc: torvalds@transmeta.com (Linus Torvalds), mingo@elte.hu,
        matthew@hairy.beasts.org (Matthew Kirkwood),
        bcrl@redhat.com (Benjamin LaHaise), david@mysql.com (David Axmark),
        wli@holomorphy.com (William Lee Irwin III),
        linux-kernel@vger.kernel.org
In-Reply-To: <E16fA92-0007en-00@wagner.rustcorp.com.au> from "Rusty Russell" at Feb 25, 2002 12:41:35 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16fKzB-0004qY-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > 	fd = sem_initialize();
> > 	mmap(fd, ...)
> > 	..
> > 	munmap(..)
> > 
> > which gives you a handle for the semaphore.
> 
> No no no!  Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.

All Linus forgot was to sem_initialize("filename"); With that the rest
comes out for free.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293521AbSBZFvN>; Tue, 26 Feb 2002 00:51:13 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293522AbSBZFvM>; Tue, 26 Feb 2002 00:51:12 -0500
Received: from [202.135.142.194] ([202.135.142.194]:18 "EHLO
	haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP
	id <S293521AbSBZFuw>; Tue, 26 Feb 2002 00:50:52 -0500
From: Rusty Russell <rusty@rustcorp.com.au>
To: Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-Reply-To: Your message of "Sun, 24 Feb 2002 23:02:58 CDT."
             <Pine.GSO.4.21.0202242230370.1549-100000@weyl.math.psu.edu> 
Date: Tue, 26 Feb 2002 16:50:26 +1100
Message-Id: <E16faVS-0000F5-00@wagner.rustcorp.com.au>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

In message <Pine.GSO.4.21.0202242230370.1549-100000@weyl.math.psu.edu> you write:
> Honour or not, in this case your complaint is hardly deserved.  To
> compress the above a bit:
> 
> you: <false statement>
> me: RTFS.  <short description of the reasons why statement is wrong; further
> details could be obtained by reading TFS>

Al, *please* read.

Rusty said:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you
> have some arbitrary limit on the number of semaphores.  Thirdly,
> someone has to own them.

These are all true: I was criticising the "fd == semaphore" approach,
in the context of my "tied to mapped location" approach, and Linus's
"magic cookie" approach.

I went on to explain furthur:

> Consider tdb, the Trivial Database.  There is no "master locking
> daemon".  There is no way for the first opener (who then has to create
> the semaphores in your model) to pass them to other openers: this is a
> library.

You also managed to ignore my previous comment on the "fd ==
semaphore" approach:

> Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.

And you came out assuming I had no idea how fd passing works:

> Yes, you can.  Please, RTFS

...and then in the next mail you suggested I implement a "master
locking daemon".

I have taken the liberty of rewriting your reply as I might expect to
see from a peer:

================
From: Al Viro's Polite Twin
To: Rusty Russell
Subject: Re: [PATCH] Lightweight userspace semaphores... 
Date: Two days after hell freezes over

On Mon, 25 Feb 2002, Rusty Russell wrote:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you

Have you considered using a daemon to hold the fds?  It shouldn't be
that bad.

================

See how it doesn't assume that I am an idiot?  It's not condescending,
and invites furthur consideration.  It's also shorter than your other
two replies.

I might have replied as follows:

		Yes, and for a "serious" database it's not a problem, as
	it usually has some kind of daemon anyway.  But for TDB, I
	found that it's fragile and extremely unwieldy.  Creating a
	unix domain socket for each .tdb file may not be possible.
	The tdb_open call would have to fork off a daemon if it's the
	first process to access it.  It starts to get fairly icky:
	certainly when compared with the fairly trivial patch to
	support the "semaphore tied to mapped region" approach.

		You can try if you want (TDB enclosed).

Maybe I'm the only one who finds it *really* painful to continually
deal with your "Dan Bernstein of Linux" approach: enough that it
hinders my kernel work.

Genuinely hope this helps,
Rusty.
--
  Taste: it's not just for source code anymore...

#ifndef __TDB_H__
#define __TDB_H__
/* 
   Unix SMB/Netbios implementation.
   Version 3.0
   Samba database functions
   Copyright (C) Andrew Tridgell 1999
   
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
   
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
   
   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#ifdef  __cplusplus
extern "C" {
#endif

/* flags to tdb_store() */
#define TDB_REPLACE 1
#define TDB_INSERT 2
#define TDB_MODIFY 3

/* flags for tdb_open() */
#define TDB_DEFAULT 0 /* just a readability place holder */
#define TDB_CLEAR_IF_FIRST 1
#define TDB_INTERNAL 2 /* don't store on disk */
#define TDB_NOLOCK   4 /* don't do any locking */
#define TDB_NOMMAP   8 /* don't use mmap */
#define TDB_CONVERT 16 /* convert endian (internal use) */

#define TDB_ERRCODE(code, ret) ((tdb->ecode = (code)), ret)

/* error codes */
enum TDB_ERROR {TDB_SUCCESS=0, TDB_ERR_CORRUPT, TDB_ERR_IO, TDB_ERR_LOCK, 
		TDB_ERR_OOM, TDB_ERR_EXISTS, TDB_ERR_NOEXIST, TDB_ERR_NOLOCK };

#ifndef u32
#define u32 unsigned
#endif

typedef struct {
	char *dptr;
	size_t dsize;
} TDB_DATA;

typedef u32 tdb_len;
typedef u32 tdb_off;

/* this is stored at the front of every database */
struct tdb_header {
	char magic_food[32]; /* for /etc/magic */
	u32 version; /* version of the code */
	u32 hash_size; /* number of hash entries */
	tdb_off rwlocks;
	tdb_off reserved[31];
};

struct tdb_lock_type {
	u32 count;
	u32 ltype;
};

struct tdb_traverse_lock {
	struct tdb_traverse_lock *next;
	u32 off;
	u32 hash;
};

/* this is the context structure that is returned from a db open */
typedef struct tdb_context {
	char *name; /* the name of the database */
	void *map_ptr; /* where it is currently mapped */
	int fd; /* open file descriptor for the database */
	tdb_len map_size; /* how much space has been mapped */
	int read_only; /* opened read-only */
	struct tdb_lock_type *locked; /* array of chain locks */
	enum TDB_ERROR ecode; /* error code for last tdb error */
	struct tdb_header header; /* a cached copy of the header */
	u32 flags; /* the flags passed to tdb_open */
	u32 *lockedkeys; /* array of locked keys: first is #keys */
	struct tdb_traverse_lock travlocks; /* current traversal locks */
	struct tdb_context *next; /* all tdbs to avoid multiple opens */
	dev_t device;	/* uniquely identifies this tdb */
	ino_t inode;	/* uniquely identifies this tdb */
} TDB_CONTEXT;

typedef int (*tdb_traverse_func)(TDB_CONTEXT *, TDB_DATA, TDB_DATA, void *);
typedef void (*tdb_log_func)(TDB_CONTEXT *, int , const char *, ...);

TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
		      int open_flags, mode_t mode);

enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb);
const char *tdb_errorstr(TDB_CONTEXT *tdb);
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag);
int tdb_close(TDB_CONTEXT *tdb);
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb);
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state);
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[]);
void tdb_unlockkeys(TDB_CONTEXT *tdb);
int tdb_lockall(TDB_CONTEXT *tdb);
void tdb_unlockall(TDB_CONTEXT *tdb);

/* Low level locking functions: use with care */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key);
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key);

/* Debug functions. Not used in production. */
void tdb_dump_all(TDB_CONTEXT *tdb);
void tdb_printfreelist(TDB_CONTEXT *tdb);

extern TDB_DATA tdb_null;
#ifdef  __cplusplus
}
#endif

#endif /* tdb.h */

 /* 
   Unix SMB/Netbios implementation.
   Version 3.0
   Samba database functions
   Copyright (C) Andrew Tridgell              1999-2000
   Copyright (C) Luke Kenneth Casson Leighton      2000
   Copyright (C) Paul `Rusty' Russell		   2000
   Copyright (C) Jeremy Allison			   2000
   
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
   
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
   
   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include "tdb.h"

#define TDB_MAGIC_FOOD "TDB file\n"
#define TDB_VERSION (0x26011967 + 6)
#define TDB_MAGIC (0x26011999U)
#define TDB_FREE_MAGIC (~TDB_MAGIC)
#define TDB_DEAD_MAGIC (0xFEE1DEAD)
#define TDB_ALIGNMENT 4
#define MIN_REC_SIZE (2*sizeof(struct list_struct) + TDB_ALIGNMENT)
#define DEFAULT_HASH_SIZE 131
#define TDB_PAGE_SIZE 0x2000
#define FREELIST_TOP (sizeof(struct tdb_header))
#define TDB_ALIGN(x,a) (((x) + (a)-1) & ~((a)-1))
#define TDB_BYTEREV(x) (((((x)&0xff)<<24)|((x)&0xFF00)<<8)|(((x)>>8)&0xFF00)|((x)>>24))
#define TDB_DEAD(r) ((r)->magic == TDB_DEAD_MAGIC)
#define TDB_BAD_MAGIC(r) ((r)->magic != TDB_MAGIC && !TDB_DEAD(r))
#define TDB_HASH_TOP(hash) (FREELIST_TOP + (BUCKET(hash)+1)*sizeof(tdb_off))

/* lock offsets */
#define GLOBAL_LOCK 0
#define ACTIVE_LOCK 4

#ifndef MAP_FILE
#define MAP_FILE 0
#endif

#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
#endif

#define BUCKET(hash) ((hash) % tdb->header.hash_size)
TDB_DATA tdb_null;

/* all contexts, to ensure no double-opens (fcntl locks don't nest!) */
static TDB_CONTEXT *tdbs = NULL;

static void tdb_munmap(TDB_CONTEXT *tdb)
{
	if (tdb->flags & TDB_INTERNAL)
		return;

	if (tdb->map_ptr)
		munmap(tdb->map_ptr, tdb->map_size);
	tdb->map_ptr = NULL;
}

static void tdb_mmap(TDB_CONTEXT *tdb)
{
	if (tdb->flags & TDB_INTERNAL)
		return;

	if (!(tdb->flags & TDB_NOMMAP)) {
		tdb->map_ptr = mmap(NULL, tdb->map_size, 
				    PROT_READ|(tdb->read_only? 0:PROT_WRITE), 
				    MAP_SHARED|MAP_FILE, tdb->fd, 0);

		/*
		 * NB. When mmap fails it returns MAP_FAILED *NOT* NULL !!!!
		 */

		if (tdb->map_ptr == MAP_FAILED)
			tdb->map_ptr = NULL;
	} else {
		tdb->map_ptr = NULL;
	}
}

/* Endian conversion: we only ever deal with 4 byte quantities */
static void *convert(void *buf, u32 size)
{
	u32 i, *p = buf;
	for (i = 0; i < size / 4; i++)
		p[i] = TDB_BYTEREV(p[i]);
	return buf;
}
#define DOCONV() (tdb->flags & TDB_CONVERT)
#define CONVERT(x) (DOCONV() ? convert(&x, sizeof(x)) : &x)

/* the body of the database is made of one list_struct for the free space
   plus a separate data list for each hash value */
struct list_struct {
	tdb_off next; /* offset of the next record in the list */
	tdb_len rec_len; /* total byte length of record */
	tdb_len key_len; /* byte length of key */
	tdb_len data_len; /* byte length of data */
	u32 full_hash; /* the full 32 bit hash of the key */
	u32 magic;   /* try to catch errors */
	/* the following union is implied:
		union {
			char record[rec_len];
			struct {
				char key[key_len];
				char data[data_len];
			}
			u32 totalsize; (tailer)
		}
	*/
};

/* a byte range locking function - return 0 on success
   this functions locks/unlocks 1 byte at the specified offset.

   On error, errno is also set so that errors are passed back properly
   through tdb_open(). */
static int tdb_brlock(TDB_CONTEXT *tdb, tdb_off offset, 
		      int rw_type, int lck_type)
{
	struct flock fl;

	if (tdb->flags & TDB_NOLOCK)
		return 0;
	if (tdb->read_only) {
		errno = EACCES;
		return -1;
	}

	fl.l_type = rw_type;
	fl.l_whence = SEEK_SET;
	fl.l_start = offset;
	fl.l_len = 1;
	fl.l_pid = 0;

	if (fcntl(tdb->fd,lck_type,&fl)) {
		/* errno set by fcntl */
		return TDB_ERRCODE(TDB_ERR_LOCK, -1);
	}
	return 0;
}

/* lock a list in the database. list -1 is the alloc list */
static int tdb_lock(TDB_CONTEXT *tdb, int list, int ltype)
{
	if (list < -1 || list >= (int)tdb->header.hash_size) {
		return -1;
	}
	if (tdb->flags & TDB_NOLOCK)
		return 0;

	/* Since fcntl locks don't nest, we do a lock for the first one,
	   and simply bump the count for future ones */
	if (tdb->locked[list+1].count == 0) {
		if (tdb_brlock(tdb,FREELIST_TOP+4*list,ltype,F_SETLKW)) {
			return -1;
		}
		tdb->locked[list+1].ltype = ltype;
	}
	tdb->locked[list+1].count++;
	return 0;
}

/* unlock the database: returns void because it's too late for errors. */
static void tdb_unlock(TDB_CONTEXT *tdb, int list, int ltype)
{
	if (tdb->flags & TDB_NOLOCK)
		return;

	/* Sanity checks */
	if (list < -1 || list >= (int)tdb->header.hash_size)
		return;
	if (tdb->locked[list+1].count==0)
		return;

	if (tdb->locked[list+1].count == 1) {
		/* Down to last nested lock: unlock underneath */
		tdb_brlock(tdb, FREELIST_TOP+4*list, F_UNLCK, F_SETLKW);
	}
	tdb->locked[list+1].count--;
}

/* This is based on the hash agorithm from gdbm */
static u32 tdb_hash(TDB_DATA *key)
{
	u32 value;	/* Used to compute the hash value.  */
	u32   i;	/* Used to cycle through random values. */

	/* Set the initial value from the key size. */
	for (value = 0x238F13AF * key->dsize, i=0; i < key->dsize; i++)
		value = (value + (key->dptr[i] << (i*5 % 24)));

	return (1103515243 * value + 12345);  
}

/* check for an out of bounds access - if it is out of bounds then
   see if the database has been expanded by someone else and expand
   if necessary 
   note that "len" is the minimum length needed for the db
*/
static int tdb_oob(TDB_CONTEXT *tdb, tdb_off len)
{
	struct stat st;
	if (len <= tdb->map_size)
		return 0;
	if (tdb->flags & TDB_INTERNAL) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}

	if (fstat(tdb->fd, &st) == -1)
		return TDB_ERRCODE(TDB_ERR_IO, -1);

	if (st.st_size < (size_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}

	/* Unmap, update size, remap */
	tdb_munmap(tdb);
	tdb->map_size = st.st_size;
	tdb_mmap(tdb);
	return 0;
}

/* write a lump of data at a specified offset */
static int tdb_write(TDB_CONTEXT *tdb, tdb_off off, void *buf, tdb_len len)
{
	if (tdb_oob(tdb, off + len) != 0)
		return -1;

	if (tdb->map_ptr)
		memcpy(off + (char *)tdb->map_ptr, buf, len);
	else if (lseek(tdb->fd, off, SEEK_SET) != off
		 || write(tdb->fd, buf, len) != (ssize_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}
	return 0;
}

/* read a lump of data at a specified offset, maybe convert */
static int tdb_read(TDB_CONTEXT *tdb,tdb_off off,void *buf,tdb_len len,int cv)
{
	if (tdb_oob(tdb, off + len) != 0)
		return -1;

	if (tdb->map_ptr)
		memcpy(buf, off + (char *)tdb->map_ptr, len);
	else if (lseek(tdb->fd, off, SEEK_SET) != off
		 || read(tdb->fd, buf, len) != (ssize_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}
	if (cv)
		convert(buf, len);
	return 0;
}

/* read a lump of data, allocating the space for it */
static char *tdb_alloc_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_len len)
{
	char *buf;

	if (!(buf = malloc(len))) {
		return TDB_ERRCODE(TDB_ERR_OOM, buf);
	}
	if (tdb_read(tdb, offset, buf, len, 0) == -1) {
		free(buf);
		return NULL;
	}
	return buf;
}

/* read/write a tdb_off */
static int ofs_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
	return tdb_read(tdb, offset, (char*)d, sizeof(*d), DOCONV());
}
static int ofs_write(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
	tdb_off off = *d;
	return tdb_write(tdb, offset, CONVERT(off), sizeof(*d));
}

/* read/write a record */
static int rec_read(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	if (tdb_read(tdb, offset, rec, sizeof(*rec),DOCONV()) == -1)
		return -1;
	if (TDB_BAD_MAGIC(rec)) {
		return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
	}
	return tdb_oob(tdb, rec->next+sizeof(*rec));
}
static int rec_write(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	struct list_struct r = *rec;
	return tdb_write(tdb, offset, CONVERT(r), sizeof(r));
}

/* read a freelist record and check for simple errors */
static int rec_free_read(TDB_CONTEXT *tdb, tdb_off off, struct list_struct *rec)
{
	if (tdb_read(tdb, off, rec, sizeof(*rec),DOCONV()) == -1)
		return -1;
	if (rec->magic != TDB_FREE_MAGIC) {
		return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
	}
	if (tdb_oob(tdb, rec->next+sizeof(*rec)) != 0)
		return -1;
	return 0;
}

/* update a record tailer (must hold allocation lock) */
static int update_tailer(TDB_CONTEXT *tdb, tdb_off offset,
			 const struct list_struct *rec)
{
	tdb_off totalsize;

	/* Offset of tailer from record header */
	totalsize = sizeof(*rec) + rec->rec_len;
	return ofs_write(tdb, offset + totalsize - sizeof(tdb_off),
			 &totalsize);
}

static tdb_off tdb_dump_record(TDB_CONTEXT *tdb, tdb_off offset)
{
	struct list_struct rec;
	tdb_off tailer_ofs, tailer;

	if (tdb_read(tdb, offset, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
		printf("ERROR: failed to read record at %u\n", offset);
		return 0;
	}

	printf(" rec: offset=%u next=%d rec_len=%d key_len=%d data_len=%d full_hash=0x%x magic=0x%x\n",
	       offset, rec.next, rec.rec_len, rec.key_len, rec.data_len, rec.full_hash, rec.magic);

	tailer_ofs = offset + sizeof(rec) + rec.rec_len - sizeof(tdb_off);
	if (ofs_read(tdb, tailer_ofs, &tailer) == -1) {
		printf("ERROR: failed to read tailer at %u\n", tailer_ofs);
		return rec.next;
	}

	if (tailer != rec.rec_len + sizeof(rec)) {
		printf("ERROR: tailer does not match record! tailer=%u totalsize=%u\n", tailer, rec.rec_len + sizeof(rec));
	}
	return rec.next;
}

static void tdb_dump_chain(TDB_CONTEXT *tdb, int i)
{
	tdb_off rec_ptr, top;

	top = TDB_HASH_TOP(i);

	tdb_lock(tdb, i, F_WRLCK);

	if (ofs_read(tdb, top, &rec_ptr) == -1) {
		tdb_unlock(tdb, i, F_WRLCK);
		return;
	}

	if (rec_ptr)
		printf("hash=%d\n", i);

	while (rec_ptr) {
		rec_ptr = tdb_dump_record(tdb, rec_ptr);
	}
	tdb_unlock(tdb, i, F_WRLCK);
}

void tdb_dump_all(TDB_CONTEXT *tdb)
{
	int i;
	for (i=0;i<tdb->header.hash_size;i++) {
		tdb_dump_chain(tdb, i);
	}
	printf("freelist:\n");
	tdb_dump_chain(tdb, -1);
}

void tdb_printfreelist(TDB_CONTEXT *tdb)
{
	long total_free = 0;
	tdb_off offset, rec_ptr, last_ptr;
	struct list_struct rec;

	tdb_lock(tdb, -1, F_WRLCK);

	last_ptr = 0;
	offset = FREELIST_TOP;

	/* read in the freelist top */
	if (ofs_read(tdb, offset, &rec_ptr) == -1) {
		return;
	}

	printf("freelist top=[0x%08x]\n", rec_ptr );
	while (rec_ptr) {
		if (tdb_read(tdb, rec_ptr, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
			return;
		}

		if (rec.magic != TDB_FREE_MAGIC) {
			printf("bad magic 0x%08x in free list\n", rec.magic);
			return;
		}

		printf("entry offset=[0x%08x], rec.rec_len = [0x%08x (%d)]\n", rec.next, rec.rec_len, rec.rec_len );
		total_free += rec.rec_len;

		/* move to the next record */
		rec_ptr = rec.next;
	}
	printf("total rec_len = [0x%08x (%d)]\n", (int)total_free, 
               (int)total_free);

	tdb_unlock(tdb, -1, F_WRLCK);
}

/* Remove an element from the freelist.  Must have alloc lock. */
static int remove_from_freelist(TDB_CONTEXT *tdb, tdb_off off, tdb_off next)
{
	tdb_off last_ptr, i;

	/* read in the freelist top */
	last_ptr = FREELIST_TOP;
	while (ofs_read(tdb, last_ptr, &i) != -1 && i != 0) {
		if (i == off) {
			/* We've found it! */
			return ofs_write(tdb, last_ptr, &next);
		}
		/* Follow chain (next offset is at start of record) */
		last_ptr = i;
	}
	return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
}

/* Add an element into the freelist. Merge adjacent records if
   neccessary. */
static int tdb_free(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	tdb_off right, left;

	/* Allocation and tailer lock */
	if (tdb_lock(tdb, -1, F_WRLCK) != 0)
		return -1;

	/* set an initial tailer, so if we fail we don't leave a bogus record */
	update_tailer(tdb, offset, rec);

	/* Look right first (I'm an Australian, dammit) */
	right = offset + sizeof(*rec) + rec->rec_len;
	if (right + sizeof(*rec) <= tdb->map_size) {
		struct list_struct r;

		if (tdb_read(tdb, right, &r, sizeof(r), DOCONV()) == -1) {
			goto left;
		}

		/* If it's free, expand to include it. */
		if (r.magic == TDB_FREE_MAGIC) {
			if (remove_from_freelist(tdb, right, r.next) == -1) {
				goto left;
			}
			rec->rec_len += sizeof(r) + r.rec_len;
		}
	}

left:
	/* Look left */
	left = offset - sizeof(tdb_off);
	if (left > TDB_HASH_TOP(tdb->header.hash_size-1)) {
		struct list_struct l;
		tdb_off leftsize;

		/* Read in tailer and jump back to header */
		if (ofs_read(tdb, left, &leftsize) == -1) {
			goto update;
		}
		left = offset - leftsize;

		/* Now read in record */
		if (tdb_read(tdb, left, &l, sizeof(l), DOCONV()) == -1) {
			goto update;
		}

		/* If it's free, expand to include it. */
		if (l.magic == TDB_FREE_MAGIC) {
			if (remove_from_freelist(tdb, left, l.next) == -1) {
				goto update;
			} else {
				offset = left;
				rec->rec_len += leftsize;
			}
		}
	}

update:
	if (update_tailer(tdb, offset, rec) == -1) {
		goto fail;
	}

	/* Now, prepend to free list */
	rec->magic = TDB_FREE_MAGIC;

	if (ofs_read(tdb, FREELIST_TOP, &rec->next) == -1 ||
	    rec_write(tdb, offset, rec) == -1 ||
	    ofs_write(tdb, FREELIST_TOP, &offset) == -1) {
		goto fail;
	}

	/* And we're done. */
	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;

 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return -1;
}


/* expand a file.  we prefer to use ftruncate, as that is what posix
  says to use for mmap expansion */
static int expand_file(TDB_CONTEXT *tdb, tdb_off size, tdb_off addition)
{
	char buf[1024];

	if (ftruncate(tdb->fd, size+addition) != 0) {
		return -1;
	}

	/* now fill the file with something. This ensures that the file isn't sparse, which would be
	   very bad if we ran out of disk. This must be done with write, not via mmap */
	memset(buf, 0x42, sizeof(buf));
	while (addition) {
		int n = addition>sizeof(buf)?sizeof(buf):addition;
		int ret;
		if (lseek(tdb->fd, size, SEEK_SET) != size)
			return -1;
		ret = write(tdb->fd, buf, n);
		if (ret != n) {
			return -1;
		}
		addition -= n;
		size += n;
	}
	return 0;
}


/* expand the database at least size bytes by expanding the underlying
   file and doing the mmap again if necessary */
static int tdb_expand(TDB_CONTEXT *tdb, tdb_off size)
{
	struct list_struct rec;
	tdb_off offset;

	if (tdb_lock(tdb, -1, F_WRLCK) == -1) {
		return -1;
	}

	/* must know about any previous expansions by another process */
	tdb_oob(tdb, tdb->map_size + 1);

	/* always make room for at least 10 more records, and round
           the database up to a multiple of TDB_PAGE_SIZE */
	size = TDB_ALIGN(tdb->map_size + size*10, TDB_PAGE_SIZE) - tdb->map_size;

	if (!(tdb->flags & TDB_INTERNAL))
		tdb_munmap(tdb);

	/*
	 * We must ensure the file is unmapped before doing this
	 * to ensure consistency with systems like OpenBSD where
	 * writes and mmaps are not consistent.
	 */

	/* expand the file itself */
	if (!(tdb->flags & TDB_INTERNAL)) {
		if (expand_file(tdb, tdb->map_size, size) != 0)
			goto fail;
	}

	tdb->map_size += size;

	if (tdb->flags & TDB_INTERNAL)
		tdb->map_ptr = realloc(tdb->map_ptr, tdb->map_size);
	else {
		/*
		 * We must ensure the file is remapped before adding the space
		 * to ensure consistency with systems like OpenBSD where
		 * writes and mmaps are not consistent.
		 */

		/* We're ok if the mmap fails as we'll fallback to read/write */
		tdb_mmap(tdb);
	}

	/* form a new freelist record */
	memset(&rec,'\0',sizeof(rec));
	rec.rec_len = size - sizeof(rec);

	/* link it into the free list */
	offset = tdb->map_size - size;
	if (tdb_free(tdb, offset, &rec) == -1)
		goto fail;

	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;
 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return -1;
}

/* allocate some space from the free list. The offset returned points
   to a unconnected list_struct within the database with room for at
   least length bytes of total data

   0 is returned if the space could not be allocated
 */
static tdb_off tdb_allocate(TDB_CONTEXT *tdb, tdb_len length,
			    struct list_struct *rec)
{
	tdb_off rec_ptr, last_ptr, newrec_ptr;
	struct list_struct newrec;

	if (tdb_lock(tdb, -1, F_WRLCK) == -1)
		return 0;

	/* Extra bytes required for tailer */
	length += sizeof(tdb_off);

 again:
	last_ptr = FREELIST_TOP;

	/* read in the freelist top */
	if (ofs_read(tdb, FREELIST_TOP, &rec_ptr) == -1)
		goto fail;

	/* keep looking until we find a freelist record big enough */
	while (rec_ptr) {
		if (rec_free_read(tdb, rec_ptr, rec) == -1)
			goto fail;

		if (rec->rec_len >= length) {
			/* found it - now possibly split it up  */
			if (rec->rec_len > length + MIN_REC_SIZE) {
				/* Length of left piece */
				length = TDB_ALIGN(length, TDB_ALIGNMENT);

				/* Right piece to go on free list */
				newrec.rec_len = rec->rec_len
					- (sizeof(*rec) + length);
				newrec_ptr = rec_ptr + sizeof(*rec) + length;

				/* And left record is shortened */
				rec->rec_len = length;
			} else
				newrec_ptr = 0;

			/* Remove allocated record from the free list */
			if (ofs_write(tdb, last_ptr, &rec->next) == -1)
				goto fail;

			/* Update header: do this before we drop alloc
                           lock, otherwise tdb_free() might try to
                           merge with us, thinking we're free.
                           (Thanks Jeremy Allison). */
			rec->magic = TDB_MAGIC;
			if (rec_write(tdb, rec_ptr, rec) == -1)
				goto fail;

			/* Did we create new block? */
			if (newrec_ptr) {
				/* Update allocated record tailer (we
                                   shortened it). */
				if (update_tailer(tdb, rec_ptr, rec) == -1)
					goto fail;

				/* Free new record */
				if (tdb_free(tdb, newrec_ptr, &newrec) == -1)
					goto fail;
			}

			/* all done - return the new record offset */
			tdb_unlock(tdb, -1, F_WRLCK);
			return rec_ptr;
		}
		/* move to the next record */
		last_ptr = rec_ptr;
		rec_ptr = rec->next;
	}
	/* we didn't find enough space. See if we can expand the
	   database and if we can then try again */
	if (tdb_expand(tdb, length + sizeof(*rec)) == 0)
		goto again;
 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;
}

/* initialise a new database with a specified hash size */
static int tdb_new_database(TDB_CONTEXT *tdb, int hash_size)
{
	struct tdb_header *newdb;
	int size, ret = -1;

	/* We make it up in memory, then write it out if not internal */
	size = sizeof(struct tdb_header) + (hash_size+1)*sizeof(tdb_off);
	if (!(newdb = calloc(size, 1)))
		return TDB_ERRCODE(TDB_ERR_OOM, -1);

	/* Fill in the header */
	newdb->version = TDB_VERSION;
	newdb->hash_size = hash_size;
	if (tdb->flags & TDB_INTERNAL) {
		tdb->map_size = size;
		tdb->map_ptr = (char *)newdb;
		memcpy(&tdb->header, newdb, sizeof(tdb->header));
		/* Convert the `ondisk' version if asked. */
		CONVERT(*newdb);
		return 0;
	}
	if (lseek(tdb->fd, 0, SEEK_SET) == -1)
		goto fail;

	if (ftruncate(tdb->fd, 0) == -1)
		goto fail;

	/* This creates an endian-converted header, as if read from disk */
	CONVERT(*newdb);
	memcpy(&tdb->header, newdb, sizeof(tdb->header));
	/* Don't endian-convert the magic food! */
	memcpy(newdb->magic_food, TDB_MAGIC_FOOD, strlen(TDB_MAGIC_FOOD)+1);
	if (write(tdb->fd, newdb, size) != size)
		ret = -1;
	else
		ret = 0;

  fail:
	free(newdb);
	return ret;
}

/* Returns 0 on fail.  On success, return offset of record, and fills
   in rec */
static tdb_off tdb_find(TDB_CONTEXT *tdb, TDB_DATA key, u32 hash,
			struct list_struct *r)
{
	tdb_off rec_ptr;
	
	/* read in the hash top */
	if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1)
		return 0;

	/* keep looking until we find the right record */
	while (rec_ptr) {
		if (rec_read(tdb, rec_ptr, r) == -1)
			return 0;

		if (!TDB_DEAD(r) && hash==r->full_hash && key.dsize==r->key_len) {
			char *k;
			/* a very likely hit - read the key */
			k = tdb_alloc_read(tdb, rec_ptr + sizeof(*r), 
					   r->key_len);
			if (!k)
				return 0;

			if (memcmp(key.dptr, k, key.dsize) == 0) {
				free(k);
				return rec_ptr;
			}
			free(k);
		}
		rec_ptr = r->next;
	}
	return TDB_ERRCODE(TDB_ERR_NOEXIST, 0);
}

/* If they do lockkeys, check that this hash is one they locked */
static int tdb_keylocked(TDB_CONTEXT *tdb, u32 hash)
{
	u32 i;
	if (!tdb->lockedkeys)
		return 1;
	for (i = 0; i < tdb->lockedkeys[0]; i++)
		if (tdb->lockedkeys[i+1] == hash)
			return 1;
	return TDB_ERRCODE(TDB_ERR_NOLOCK, 0);
}

/* As tdb_find, but if you succeed, keep the lock */
static tdb_off tdb_find_lock(TDB_CONTEXT *tdb, TDB_DATA key, int locktype,
			     struct list_struct *rec)
{
	u32 hash, rec_ptr;

	hash = tdb_hash(&key);
	if (!tdb_keylocked(tdb, hash))
		return 0;
	if (tdb_lock(tdb, BUCKET(hash), locktype) == -1)
		return 0;
	if (!(rec_ptr = tdb_find(tdb, key, hash, rec)))
		tdb_unlock(tdb, BUCKET(hash), locktype);
	return rec_ptr;
}

enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb)
{
	return tdb->ecode;
}

static struct tdb_errname {
	enum TDB_ERROR ecode; const char *estring;
} emap[] = { {TDB_SUCCESS, "Success"},
	     {TDB_ERR_CORRUPT, "Corrupt database"},
	     {TDB_ERR_IO, "IO Error"},
	     {TDB_ERR_LOCK, "Locking error"},
	     {TDB_ERR_OOM, "Out of memory"},
	     {TDB_ERR_EXISTS, "Record exists"},
	     {TDB_ERR_NOLOCK, "Lock exists on other keys"},
	     {TDB_ERR_NOEXIST, "Record does not exist"} };

/* Error string for the last tdb error */
const char *tdb_errorstr(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i = 0; i < sizeof(emap) / sizeof(struct tdb_errname); i++)
		if (tdb->ecode == emap[i].ecode)
			return emap[i].estring;
	return "Invalid error code";
}

/* update an entry in place - this only works if the new data size
   is <= the old data size and the key exists.
   on failure return -1
*/
static int tdb_update(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf)
{
	struct list_struct rec;
	tdb_off rec_ptr;
	int ret = -1;

	/* find entry */
	if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
		return -1;

	/* must be long enough key, data and tailer */
	if (rec.rec_len < key.dsize + dbuf.dsize + sizeof(tdb_off)) {
		tdb->ecode = TDB_SUCCESS; /* Not really an error */
		goto out;
	}

	if (tdb_write(tdb, rec_ptr + sizeof(rec) + rec.key_len,
		      dbuf.dptr, dbuf.dsize) == -1)
		goto out;

	if (dbuf.dsize != rec.data_len) {
		/* update size */
		rec.data_len = dbuf.dsize;
		ret = rec_write(tdb, rec_ptr, &rec);
	} else
		ret = 0;
 out:
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
	return ret;
}

/* find an entry in the database given a key */
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_off rec_ptr;
	struct list_struct rec;
	TDB_DATA ret;

	/* find which hash bucket it is in */
	if (!(rec_ptr = tdb_find_lock(tdb,key,F_RDLCK,&rec)))
		return tdb_null;

	ret.dptr = tdb_alloc_read(tdb, rec_ptr + sizeof(rec) + rec.key_len,
				  rec.data_len);
	ret.dsize = rec.data_len;
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
	return ret;
}

/* check if an entry in the database exists 

   note that 1 is returned if the key is found and 0 is returned if not found
   this doesn't match the conventions in the rest of this module, but is
   compatible with gdbm
*/
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key)
{
	struct list_struct rec;
	
	if (tdb_find_lock(tdb, key, F_RDLCK, &rec) == 0)
		return 0;
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
	return 1;
}

/* record lock stops delete underneath */
static int lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	return off ? tdb_brlock(tdb, off, F_RDLCK, F_SETLKW) : 0;
}
/*
  Write locks override our own fcntl readlocks, so check it here.
  Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
  an error to fail to get the lock here.
*/
 
static int write_lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	struct tdb_traverse_lock *i;
	for (i = &tdb->travlocks; i; i = i->next)
		if (i->off == off)
			return -1;
	return tdb_brlock(tdb, off, F_WRLCK, F_SETLK);
}

/*
  Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
  an error to fail to get the lock here.
*/

static int write_unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	return tdb_brlock(tdb, off, F_UNLCK, F_SETLK);
}
/* fcntl locks don't stack: avoid unlocking someone else's */
static int unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	struct tdb_traverse_lock *i;
	u32 count = 0;

	if (off == 0)
		return 0;
	for (i = &tdb->travlocks; i; i = i->next)
		if (i->off == off)
			count++;
	return (count == 1 ? tdb_brlock(tdb, off, F_UNLCK, F_SETLKW) : 0);
}

/* actually delete an entry in the database given the offset */
static int do_delete(TDB_CONTEXT *tdb, tdb_off rec_ptr, struct list_struct*rec)
{
	tdb_off last_ptr, i;
	struct list_struct lastrec;

	if (tdb->read_only) return -1;

	if (write_lock_record(tdb, rec_ptr) == -1) {
		/* Someone traversing here: mark it as dead */
		rec->magic = TDB_DEAD_MAGIC;
		return rec_write(tdb, rec_ptr, rec);
	}
	write_unlock_record(tdb, rec_ptr);

	/* find previous record in hash chain */
	if (ofs_read(tdb, TDB_HASH_TOP(rec->full_hash), &i) == -1)
		return -1;
	for (last_ptr = 0; i != rec_ptr; last_ptr = i, i = lastrec.next)
		if (rec_read(tdb, i, &lastrec) == -1)
			return -1;

	/* unlink it: next ptr is at start of record. */
	if (last_ptr == 0)
		last_ptr = TDB_HASH_TOP(rec->full_hash);
	if (ofs_write(tdb, last_ptr, &rec->next) == -1)
		return -1;

	/* recover the space */
	if (tdb_free(tdb, rec_ptr, rec) == -1)
		return -1;
	return 0;
}

/* Uses traverse lock: 0 = finish, -1 = error, other = record offset */
static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
			 struct list_struct *rec)
{
	int want_next = (tlock->off != 0);

	/* No traversal allows if you've called tdb_lockkeys() */
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);

	/* Lock each chain from the start one. */
	for (; tlock->hash < tdb->header.hash_size; tlock->hash++) {
		if (tdb_lock(tdb, tlock->hash, F_WRLCK) == -1)
			return -1;

		/* No previous record?  Start at top of chain. */
		if (!tlock->off) {
			if (ofs_read(tdb, TDB_HASH_TOP(tlock->hash),
				     &tlock->off) == -1)
				goto fail;
		} else {
			/* Otherwise unlock the previous record. */
			unlock_record(tdb, tlock->off);
		}

		if (want_next) {
			/* We have offset of old record: grab next */
			if (rec_read(tdb, tlock->off, rec) == -1)
				goto fail;
			tlock->off = rec->next;
		}

		/* Iterate through chain */
		while( tlock->off) {
			tdb_off current;
			if (rec_read(tdb, tlock->off, rec) == -1)
				goto fail;
			if (!TDB_DEAD(rec)) {
				/* Woohoo: we found one! */
				lock_record(tdb, tlock->off);
				return tlock->off;
			}
			/* Try to clean dead ones from old traverses */
			current = tlock->off;
			tlock->off = rec->next;
			do_delete(tdb, current, rec);
		}
		tdb_unlock(tdb, tlock->hash, F_WRLCK);
		want_next = 0;
	}
	/* We finished iteration without finding anything */
	return TDB_ERRCODE(TDB_SUCCESS, 0);

 fail:
	tlock->off = 0;
	tdb_unlock(tdb, tlock->hash, F_WRLCK);
	return -1;
}

/* traverse the entire database - calling fn(tdb, key, data) on each element.
   return -1 on error or the record count traversed
   if fn is NULL then it is not called
   a non-zero return value from fn() indicates that the traversal should stop
  */
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state)
{
	TDB_DATA key, dbuf;
	struct list_struct rec;
	struct tdb_traverse_lock tl = { NULL, 0, 0 };
	int ret, count = 0;

	/* This was in the initializaton, above, but the IRIX compiler
	 * did not like it.  crh
	 */
	tl.next = tdb->travlocks.next;

	/* fcntl locks don't stack: beware traverse inside traverse */
	tdb->travlocks.next = &tl;

	/* tdb_next_lock places locks on the record returned, and its chain */
	while ((ret = tdb_next_lock(tdb, &tl, &rec)) > 0) {
		count++;
		/* now read the full record */
		key.dptr = tdb_alloc_read(tdb, tl.off + sizeof(rec), 
					  rec.key_len + rec.data_len);
		if (!key.dptr) {
			tdb_unlock(tdb, tl.hash, F_WRLCK);
			unlock_record(tdb, tl.off);
			tdb->travlocks.next = tl.next;
			return -1;
		}
		key.dsize = rec.key_len;
		dbuf.dptr = key.dptr + rec.key_len;
		dbuf.dsize = rec.data_len;

		/* Drop chain lock, call out */
		tdb_unlock(tdb, tl.hash, F_WRLCK);
		if (fn && fn(tdb, key, dbuf, state)) {
			/* They want us to terminate traversal */
			unlock_record(tdb, tl.off);
			tdb->travlocks.next = tl.next;
			free(key.dptr);
			return count;
		}
		free(key.dptr);
	}
	tdb->travlocks.next = tl.next;
	if (ret < 0)
		return -1;
	else
		return count;
}

/* find the first entry in the database and return its key */
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb)
{
	TDB_DATA key;
	struct list_struct rec;

	/* release any old lock */
	unlock_record(tdb, tdb->travlocks.off);
	tdb->travlocks.off = tdb->travlocks.hash = 0;

	if (tdb_next_lock(tdb, &tdb->travlocks, &rec) <= 0)
		return tdb_null;
	/* now read the key */
	key.dsize = rec.key_len;
	key.dptr =tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),key.dsize);
	tdb_unlock(tdb, BUCKET(tdb->travlocks.hash), F_WRLCK);
	return key;
}

/* find the next entry in the database, returning its key */
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA oldkey)
{
	u32 oldhash;
	TDB_DATA key = tdb_null;
	struct list_struct rec;
	char *k = NULL;

	/* Is locked key the old key?  If so, traverse will be reliable. */
	if (tdb->travlocks.off) {
		if (tdb_lock(tdb,tdb->travlocks.hash,F_WRLCK))
			return tdb_null;
		if (rec_read(tdb, tdb->travlocks.off, &rec) == -1
		    || !(k = tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),
					    rec.key_len))
		    || memcmp(k, oldkey.dptr, oldkey.dsize) != 0) {
			/* No, it wasn't: unlock it and start from scratch */
			unlock_record(tdb, tdb->travlocks.off);
			tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
			tdb->travlocks.off = 0;
		}

		if (k)
			free(k);
	}

	if (!tdb->travlocks.off) {
		/* No previous element: do normal find, and lock record */
		tdb->travlocks.off = tdb_find_lock(tdb, oldkey, F_WRLCK, &rec);
		if (!tdb->travlocks.off)
			return tdb_null;
		tdb->travlocks.hash = BUCKET(rec.full_hash);
		lock_record(tdb, tdb->travlocks.off);
	}
	oldhash = tdb->travlocks.hash;

	/* Grab next record: locks chain and returned record,
	   unlocks old record */
	if (tdb_next_lock(tdb, &tdb->travlocks, &rec) > 0) {
		key.dsize = rec.key_len;
		key.dptr = tdb_alloc_read(tdb, tdb->travlocks.off+sizeof(rec),
					  key.dsize);
		/* Unlock the chain of this new record */
		tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
	}
	/* Unlock the chain of old record */
	tdb_unlock(tdb, BUCKET(oldhash), F_WRLCK);
	return key;
}

/* delete an entry in the database given a key */
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_off rec_ptr;
	struct list_struct rec;
	int ret;

	if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
		return -1;
	ret = do_delete(tdb, rec_ptr, &rec);
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
	return ret;
}

/* store an element in the database, replacing any existing element
   with the same key 

   return 0 on success, -1 on failure
*/
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag)
{
	struct list_struct rec;
	u32 hash;
	tdb_off rec_ptr;
	char *p = NULL;
	int ret = 0;

	/* find which hash bucket it is in */
	hash = tdb_hash(&key);
	if (!tdb_keylocked(tdb, hash))
		return -1;
	if (tdb_lock(tdb, BUCKET(hash), F_WRLCK) == -1)
		return -1;

	/* check for it existing, on insert. */
	if (flag == TDB_INSERT) {
		if (tdb_exists(tdb, key)) {
			tdb->ecode = TDB_ERR_EXISTS;
			goto fail;
		}
	} else {
		/* first try in-place update, on modify or replace. */
		if (tdb_update(tdb, key, dbuf) == 0)
			goto out;
		if (flag == TDB_MODIFY && tdb->ecode == TDB_ERR_NOEXIST)
			goto fail;
	}
	/* reset the error code potentially set by the tdb_update() */
	tdb->ecode = TDB_SUCCESS;

	/* delete any existing record - if it doesn't exist we don't
           care.  Doing this first reduces fragmentation, and avoids
           coalescing with `allocated' block before it's updated. */
	if (flag != TDB_INSERT)
		tdb_delete(tdb, key);

	/* Copy key+value *before* allocating free space in case malloc
	   fails and we are left with a dead spot in the tdb. */

	if (!(p = (char *)malloc(key.dsize + dbuf.dsize))) {
		tdb->ecode = TDB_ERR_OOM;
		goto fail;
	}

	memcpy(p, key.dptr, key.dsize);
	memcpy(p+key.dsize, dbuf.dptr, dbuf.dsize);

	/* now we're into insert / modify / replace of a record which
	 * we know could not be optimised by an in-place store (for
	 * various reasons).  */
	if (!(rec_ptr = tdb_allocate(tdb, key.dsize + dbuf.dsize, &rec)))
		goto fail;

	/* Read hash top into next ptr */
	if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec.next) == -1)
		goto fail;

	rec.key_len = key.dsize;
	rec.data_len = dbuf.dsize;
	rec.full_hash = hash;
	rec.magic = TDB_MAGIC;

	/* write out and point the top of the hash chain at it */
	if (rec_write(tdb, rec_ptr, &rec) == -1
	    || tdb_write(tdb, rec_ptr+sizeof(rec), p, key.dsize+dbuf.dsize)==-1
	    || ofs_write(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1) {
	fail:
		/* Need to tdb_unallocate() here */
		ret = -1;
	}
 out:
	if (p)
		free(p); 
	tdb_unlock(tdb, BUCKET(hash), F_WRLCK);
	return ret;
}

static int tdb_already_open(dev_t device,
			    ino_t ino)
{
	TDB_CONTEXT *i;
	
	for (i = tdbs; i; i = i->next) {
		if (i->device == device && i->inode == ino) {
			return 1;
		}
	}

	return 0;
}

/* open the database, creating it if necessary 

   The open_flags and mode are passed straight to the open call on the
   database file. A flags value of O_WRONLY is invalid. The hash size
   is advisory, use zero for a default value.

   Return is NULL on error, in which case errno is also set.  Don't 
   try to call tdb_error or tdb_errname, just do strerror(errno).

   @param name may be NULL for internal databases. */
TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
		      int open_flags, mode_t mode)
{
	TDB_CONTEXT *tdb;
	struct stat st;
	int rev = 0, locked;

	if (!(tdb = calloc(1, sizeof *tdb))) {
		/* Can't log this */
		errno = ENOMEM;
		goto fail;
	}
	tdb->fd = -1;
	tdb->name = NULL;
	tdb->map_ptr = NULL;
	tdb->lockedkeys = NULL;
	tdb->flags = tdb_flags;
	
	if ((open_flags & O_ACCMODE) == O_WRONLY) {
		errno = EINVAL;
		goto fail;
	}
	
	if (hash_size == 0)
		hash_size = DEFAULT_HASH_SIZE;
	if ((open_flags & O_ACCMODE) == O_RDONLY) {
		tdb->read_only = 1;
		/* read only databases don't do locking or clear if first */
		tdb->flags |= TDB_NOLOCK;
		tdb->flags &= ~TDB_CLEAR_IF_FIRST;
	}

	/* internal databases don't mmap or lock, and start off cleared */
	if (tdb->flags & TDB_INTERNAL) {
		tdb->flags |= (TDB_NOLOCK | TDB_NOMMAP);
		tdb->flags &= ~TDB_CLEAR_IF_FIRST;
		tdb_new_database(tdb, hash_size);
		goto internal;
	}

	if ((tdb->fd = open(name, open_flags, mode)) == -1) {
		goto fail;	/* errno set by open(2) */
	}

	/* ensure there is only one process initialising at once */
	if (tdb_brlock(tdb, GLOBAL_LOCK, F_WRLCK, F_SETLKW) == -1) {
		goto fail;	/* errno set by tdb_brlock */
	}

	/* we need to zero database if we are the only one with it open */
	if ((locked = (tdb_brlock(tdb, ACTIVE_LOCK, F_WRLCK, F_SETLK) == 0))
	    && (tdb_flags & TDB_CLEAR_IF_FIRST)) {
		open_flags |= O_CREAT;
		if (ftruncate(tdb->fd, 0) == -1) {
			goto fail; /* errno set by ftruncate */
		}
	}

	if (read(tdb->fd, &tdb->header, sizeof(tdb->header)) != sizeof(tdb->header)
	    || strcmp(tdb->header.magic_food, TDB_MAGIC_FOOD) != 0
	    || (tdb->header.version != TDB_VERSION
		&& !(rev = (tdb->header.version==TDB_BYTEREV(TDB_VERSION))))) {
		/* its not a valid database - possibly initialise it */
		if (!(open_flags & O_CREAT) || tdb_new_database(tdb, hash_size) == -1) {
			errno = EIO; /* ie bad format or something */
			goto fail;
		}
		rev = (tdb->flags & TDB_CONVERT);
	}
	if (!rev)
		tdb->flags &= ~TDB_CONVERT;
	else {
		tdb->flags |= TDB_CONVERT;
		convert(&tdb->header, sizeof(tdb->header));
	}
	if (fstat(tdb->fd, &st) == -1)
		goto fail;

	/* Is it already in the open list?  If so, fail. */
	if (tdb_already_open(st.st_dev, st.st_ino)) {
		errno = EBUSY;
		goto fail;
	}

	if (!(tdb->name = (char *)strdup(name))) {
		errno = ENOMEM;
		goto fail;
	}

	tdb->map_size = st.st_size;
	tdb->device = st.st_dev;
	tdb->inode = st.st_ino;
	tdb->locked = calloc(tdb->header.hash_size+1, sizeof(tdb->locked[0]));
	if (!tdb->locked) {
		errno = ENOMEM;
		goto fail;
	}
	tdb_mmap(tdb);
	if (locked) {
		if (tdb_brlock(tdb, ACTIVE_LOCK, F_UNLCK, F_SETLK) == -1) {
			goto fail;
		}
	}
	/* leave this lock in place to indicate it's in use */
	if (tdb_brlock(tdb, ACTIVE_LOCK, F_RDLCK, F_SETLKW) == -1)
		goto fail;

 internal:
	/* Internal (memory-only) databases skip all the code above to
	 * do with disk files, and resume here by releasing their
	 * global lock and hooking into the active list. */
	if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW) == -1)
		goto fail;
	tdb->next = tdbs;
	tdbs = tdb;
	return tdb;

 fail:
	{ int save_errno = errno;

	if (!tdb)
		return NULL;
	
	if (tdb->map_ptr) {
		if (tdb->flags & TDB_INTERNAL)
			free(tdb->map_ptr);
		else
			tdb_munmap(tdb);
	}
	if (tdb->name)
		free(tdb->name);
	if (tdb->fd != -1)
		close(tdb->fd);
	if (tdb->locked)
		free(tdb->locked);
	errno = save_errno;
	return NULL;
	}
}

/* close a database */
int tdb_close(TDB_CONTEXT *tdb)
{
	TDB_CONTEXT **i;
	int ret = 0;

	if (tdb->map_ptr) {
		if (tdb->flags & TDB_INTERNAL)
			free(tdb->map_ptr);
		else
			tdb_munmap(tdb);
	}
	if (tdb->name)
		free(tdb->name);
	if (tdb->fd != -1)
		ret = close(tdb->fd);
	if (tdb->locked)
		free(tdb->locked);
	if (tdb->lockedkeys)
		free(tdb->lockedkeys);

	/* Remove from contexts list */
	for (i = &tdbs; *i; i = &(*i)->next) {
		if (*i == tdb) {
			*i = tdb->next;
			break;
		}
	}

	memset(tdb, 0, sizeof(*tdb));
	free(tdb);

	return ret;
}

/* lock/unlock entire database */
int tdb_lockall(TDB_CONTEXT *tdb)
{
	u32 i;

	/* There are no locks on read-only dbs */
	if (tdb->read_only)
		return TDB_ERRCODE(TDB_ERR_LOCK, -1);
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	for (i = 0; i < tdb->header.hash_size; i++) 
		if (tdb_lock(tdb, i, F_WRLCK))
			break;

	/* If error, release locks we have... */
	if (i < tdb->header.hash_size) {
		u32 j;

		for ( j = 0; j < i; j++)
			tdb_unlock(tdb, j, F_WRLCK);
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	}

	return 0;
}
void tdb_unlockall(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i=0; i < tdb->header.hash_size; i++)
		tdb_unlock(tdb, i, F_WRLCK);
}

int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[])
{
	u32 i, j, hash;

	/* Can't lock more keys if already locked */
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	if (!(tdb->lockedkeys = malloc(sizeof(u32) * (number+1))))
		return TDB_ERRCODE(TDB_ERR_OOM, -1);
	/* First number in array is # keys */
	tdb->lockedkeys[0] = number;

	/* Insertion sort by bucket */
	for (i = 0; i < number; i++) {
		hash = tdb_hash(&keys[i]);
		for (j = 0; j < i && BUCKET(tdb->lockedkeys[j+1]) < BUCKET(hash); j++);
			memmove(&tdb->lockedkeys[j+2], &tdb->lockedkeys[j+1], sizeof(u32) * (i-j));
		tdb->lockedkeys[j+1] = hash;
	}
	/* Finally, lock in order */
	for (i = 0; i < number; i++)
		if (tdb_lock(tdb, i, F_WRLCK))
			break;

	/* If error, release locks we have... */
	if (i < number) {
		for ( j = 0; j < i; j++)
			tdb_unlock(tdb, j, F_WRLCK);
		free(tdb->lockedkeys);
		tdb->lockedkeys = NULL;
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	}
	return 0;
}

/* Unlock the keys previously locked by tdb_lockkeys() */
void tdb_unlockkeys(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i = 0; i < tdb->lockedkeys[0]; i++)
		tdb_unlock(tdb, tdb->lockedkeys[i+1], F_WRLCK);
	free(tdb->lockedkeys);
	tdb->lockedkeys = NULL;
}

/* lock/unlock one hash chain. This is meant to be used to reduce
   contention - it cannot guarantee how many records will be locked */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
	return tdb_lock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_unlock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293246AbSCAPjd>; Fri, 1 Mar 2002 10:39:33 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293270AbSCAPj0>; Fri, 1 Mar 2002 10:39:26 -0500
Received: from stud.fbi.fh-darmstadt.de ([141.100.40.65]:51599 "EHLO
	stud.fbi.fh-darmstadt.de") by vger.kernel.org with ESMTP
	id <S293246AbSCAPjJ>; Fri, 1 Mar 2002 10:39:09 -0500
Date: Fri, 1 Mar 2002 16:30:33 +0100 (CET)
From: Jan-Marek Glogowski <glogow@stud.fbi.fh-darmstadt.de>
To: shura <shura@tibc.ru>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <8707.020228@tibc.ru>
Message-ID: <Pine.LNX.4.30.0203011613480.11729-100000@stud.fbi.fh-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi

> I'm setting up a new machine with a pair of IDE drives connected to
> HPT 370 controller. I defined a RAID-1 array using the HPT370 bios
> setting utility.
> Description - hard:
> motherboard Abit ST6-RAID, HPT370, 2 identical hard disks as
> primary/secondary master on ide3/ide4
> - bios:
> Primary Master:   Mirror (Raid 1) for Array #0 UDMA 5 78150 BOOT
> Primary Slave:    No drive
> Secondary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 HIDDEEN
> Secondary Slave:  No drive
> - os:
> Linux RedHat 7.1 & kernel 2.4.17
> with compilation option
> CONFIG_BLK_DEV_ATARAID_HPT=y
> Lilo:
> ...
> root=/dev/hde10

The root should be /dev/ataraid/xxx for any ata raid but that is not the
real problem...

> During system booting i see following
> ...
> ataraid/d0: ataraid/d0p1 ataraid/d0p2 ataraid/d0p3 ataraid/d0p4 <>
> Highpoint HPT370 Softwareraid driver for linux version 0.01
> Drive 0 is 76319 Mb
> Drive 6 is 76319 Mb
> Raid array consists of 2 drivers
> ...
> Kernel panic: VFS: Unable to mount root fs on 21:0a
> ...

Ataraid seems to find four partitions d0p[1234]. But as far as I know
mirroring isn't supported by the in kernel open source drivers at all -
you may look at the closed source drivers at www.highpoint-tech.com, if
you really need the "hpt native" raid.
(http://people.redhat.com/arjanv/pdcraid/ataraidhowto.html)

> Booting with option root=/dev/atarad/d0p1 ro
> (or root=/dev/ataraid/d0p10 ro)
> and etc - no effect

If you just just use need to access the harddisks from linux it is
suggested to use linux software raid (there was a discussion at lkml - if
I remember right). On modern PCs it uses < 5% CPU and is faster, as it
operates high level in the kernel, not right before the hardware, as those
"big software part, small hardware part" raid controller from Promise and
Highpoint do.

HTH

Jan-Marek


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311079AbSCMT3J>; Wed, 13 Mar 2002 14:29:09 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311072AbSCMT2x>; Wed, 13 Mar 2002 14:28:53 -0500
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:60677 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S310990AbSCMT22>; Wed, 13 Mar 2002 14:28:28 -0500
Subject: Re: your mail
To: rlievin@free.fr (=?ISO-8859-1?Q?Romain_Li=E9vin?=)
Date: Wed, 13 Mar 2002 19:43:32 +0000 (GMT)
Cc: linux-kernel@vger.kernel.org (Kernel List),
        torvalds@transmeta.com (Linus Torvalds),
        alan@lxorguk.ukuu.org.uk (Alan Cox), tim@cyberelk.net (Tim Waugh)
In-Reply-To: <1016047267.3c8fa6a3660e3@imp3-1.free.fr> from "=?ISO-8859-1?Q?Romain_Li=E9vin?=" at Mar 13, 2002 08:21:07 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16lEeq-0007F3-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> It has been tested on x86 for almost 2 years and on Alpha & Sparc too with 
> various calculators.

One oddity - some other comments

> +static int tipar_open(struct inode *inode, struct file *file)
> +{
> +       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> +
> +       if (minor >= PP_NO)
> +               return -ENXIO;  
> +       
> +       init_ti_parallel(minor);
> +
> +       MOD_INC_USE_COUNT;

You should remove these and use in 2.4 + . Also what stops multiple
simultaneous runs of init_ti_parallel if two people open it at once ?


> +static unsigned int tipar_poll(struct file *file, poll_table * wait)
> +{
> +       unsigned int mask=0;
> +       return mask;
> +}

That seems unfinished ??

> +static int tipar_ioctl(struct inode *inode, struct file *file,
> +                      unsigned int cmd, unsigned long arg)
> +       case O_NONBLOCK:
> +               file->f_flags |= O_NONBLOCK;
> +               return 0;

O_NDELAY is set by fcntl - your driver never needs this.

> +       default:
> +               retval = -EINVAL;

SuS says -ENOTTY here (lots of drivers get this wrong still)

> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> +       return -ESPIPE;
> +}

There is a generic no_llseek function

> +/* Major & minor number for character devices */
> +#define TIPAR_MAJOR   61

These don't appear to be officially assigned via lanana ?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311315AbSCMU3B>; Wed, 13 Mar 2002 15:29:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311247AbSCMU2z>; Wed, 13 Mar 2002 15:28:55 -0500
Received: from postfix3-2.free.fr ([213.228.0.169]:15085 "EHLO
	postfix3-2.free.fr") by vger.kernel.org with ESMTP
	id <S311315AbSCMU2k>; Wed, 13 Mar 2002 15:28:40 -0500
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: your mail
Message-ID: <1016051318.3c8fb67699ae8@imp.free.fr>
Date: Wed, 13 Mar 2002 21:28:38 +0100 (MET)
From: =?ISO-8859-1?Q?Romain_Li=E9vin?= <rlievin@free.fr>
Cc: Kernel List <linux-kernel@vger.kernel.org>
In-Reply-To: <E16lEeq-0007F3-00@the-village.bc.nu>
In-Reply-To: <E16lEeq-0007F3-00@the-village.bc.nu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.42
X-Originating-IP: 195.220.37.21
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:

> > It has been tested on x86 for almost 2 years and on Alpha & Sparc too
> with 
> > various calculators.
> 
> One oddity - some other comments
> 
> > +static int tipar_open(struct inode *inode, struct file *file)
> > +{
> > +       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> > +
> > +       if (minor >= PP_NO)
> > +               return -ENXIO;  
> > +       
> > +       init_ti_parallel(minor);
> > +
> > +       MOD_INC_USE_COUNT;
> 
> You should remove these and use in 2.4 + . Also what stops multiple
> simultaneous runs of init_ti_parallel if two people open it at once ?
> 
> 
> > +static unsigned int tipar_poll(struct file *file, poll_table *
> wait)
> > +{
> > +       unsigned int mask=0;
> > +       return mask;
> > +}
> 
> That seems unfinished ??
> 
> > +static int tipar_ioctl(struct inode *inode, struct file *file,
> > +                      unsigned int cmd, unsigned long arg)
> > +       case O_NONBLOCK:
> > +               file->f_flags |= O_NONBLOCK;
> > +               return 0;
> 
> O_NDELAY is set by fcntl - your driver never needs this.
> 
> > +       default:
> > +               retval = -EINVAL;
> 
> SuS says -ENOTTY here (lots of drivers get this wrong still)
> 
> > +static long long tipar_lseek(struct file * file, long long offset,
> int origin)
> > +{
> > +       return -ESPIPE;
> > +}
> 
> There is a generic no_llseek function
> 
> > +/* Major & minor number for character devices */
> > +#define TIPAR_MAJOR   61
> 
> These don't appear to be officially assigned via lanana ?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Fixed some stuffs according to your remarks.

Comments are welcome...

=================== [ cuts here ] =====================
--- linux.orig/drivers/char/tipar.c     Wed Mar 13 19:19:10 2002
+++ linux/drivers/char/tipar.c  Wed Mar 13 21:24:51 2002
@@ -0,0 +1,543 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar - low level driver for handling a parallel link cable
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#define VERSION "1.12"
+
+/* This driver should, in theory, work with any parallel port that has an
+ * appropriate low-level driver; all I/O is done through the parport
+ * abstraction layer.
+ *
+ * If this driver is built into the kernel, you can configure it using the
+ * kernel command-line.  For example:
+ *
+ *      tipar=timeout,delay       (set timeout and delay)
+ *
+ * If the driver is loaded as a module, similar functionality is available
+ * using module parameters.  The equivalent of the above commands would be:
+ *
+ *      # insmod tipar.o tipar=15,10
+ */
+
+/* COMPATIBILITY WITH OLD KERNELS
+ *
+ * Usually, parallel cables were bound to ports at
+ * particular I/O addresses, as follows:
+ *
+ *      tipar0             0x378
+ *      tipar1             0x278
+ *      tipar2             0x3bc
+ *
+ *
+ * This driver, by default, binds tipar devices according to parport and
+ * the minor number.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/init.h>
+#include <asm/uaccess.h>
+#include <linux/ioport.h>
+#include <linux/errno.h>
+#include <linux/sched.h>
+#include <linux/fs.h>
+#include <asm/io.h>
+#include <linux/devfs_fs_kernel.h>
+#include <linux/parport.h> /* Our code depend on parport */
+
+/*
+ * TI definitions
+ */
+#include <linux/ticable.h>
+
+/*
+ * Deal with CONFIG_MODVERSIONS
+ */
+#if 0 /* Pb with MODVERSIONS */
+#if CONFIG_MODVERSIONS==1
+#define MODVERSIONS
+#include <linux/modversions.h>
+#endif
+#endif
+
+/* ----- global variables --------------------------------------------- */
+
+struct tipar_struct {
+       struct pardevice *dev;                  /* Parport device entry */
+       int opened;
+};
+
+#define PP_NO 3
+struct tipar_struct  table[PP_NO];
+
+static int delay   = IO_DELAY;      /* inter-bit delay in microseconds */
+static int timeout = TIMAXTIME;     /* timeout in tenth of seconds     */
+
+static devfs_handle_t devfs_handle = NULL;
+static unsigned int tp_count = 0;   /* tipar_count */
+
+/* --- macros for parport access -------------------------------------- */
+
+#define r_dtr(x)        (parport_read_data(table[(x)].dev->port))
+#define r_str(x)        (parport_read_status(table[(x)].dev->port))
+#define w_ctr(x,y)      (parport_write_control(table[(x)].dev->port, (y)))
+#define w_dtr(x,y)      (parport_write_data(table[(x)].dev->port, (y)))
+
+/* --- setting states on the D-bus with the right timing: ------------- */
+
+static inline void outbyte(int value, int minor)
+{
+       w_dtr(minor, value);
+}
+
+static inline int inbyte(int minor)
+{
+       return (r_str(minor) & 0x30);
+}
+
+static inline void init_ti_parallel(int minor)
+{
+       outbyte(3, minor);
+}
+
+/* ----- global defines ----------------------------------------------- */
+
+#define START(x) { max=jiffies+HZ/(timeout/10); }
+#define WAIT(x) { if(!time_before(jiffies, (x))) return -1; schedule(); }
+
+/* ----- D-bus bit-banging functions ---------------------------------- */
+
+/* D-bus protocol:
+                    1                 0                      0
+       _______        ______|______    __________|________    __________
+Red  :        ________      |      ____          |        ____
+       _        ____________|________      ______|__________       _____
+White:  ________            |        ______      |          _______
+*/
+
+/* Try to transmit a byte on the specified port (-1 if error). */
+static int put_ti_parallel(int minor, unsigned char data)
+{
+       int bit, i;
+       unsigned long max;
+  
+       for (bit=0; bit<8; bit++) {
+               if (data & 1) {
+                       outbyte(2, minor);
+                       START(max); 
+                       do {
+                               WAIT(max);
+                       } while (inbyte(minor) & 0x10);
+                       
+                       outbyte(3, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x10));
+               } else {
+                       outbyte(1, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (inbyte(minor) & 0x20);
+                       
+                       outbyte(3, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x20));
+               }
+               data >>= 1;
+               for(i=0; i < delay; i++) {
+                       inbyte(minor);
+               }
+               schedule();
+       }
+       
+       return 0;
+}
+
+/* Receive a byte on the specified port or -1 if error. */
+static int get_ti_parallel(int minor)
+{
+       int bit,i;
+       unsigned char v, data=0;
+       unsigned long max;
+
+       for (bit=0; bit<8; bit++) {
+               START(max); 
+               do {
+                       WAIT(max);
+               } while ((v=inbyte(minor) & 0x30) == 0x30);
+      
+               if (v == 0x10) { 
+                       data=(data>>1) | 0x80;
+                       outbyte(1, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x20));
+                       outbyte(3, minor);
+               } else {
+                       data=data>>1;
+                       outbyte(2, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x10));
+                       outbyte(3, minor);
+               }
+               for(i=0; i<delay; i++) {
+                       inbyte(minor);
+               }
+               schedule();
+       }
+       return (int)data;
+}
+
+/* Return non zero if both lines are at logical one */
+static int check_ti_parallel(int minor)
+{
+       return ((inbyte(minor) & 0x30) == 0x30);
+}
+
+/* Try to detect a parallel link cable on the specified port */
+static int probe_ti_parallel(int minor)
+{
+       int i, j;
+       int seq[]={ 0x00, 0x20, 0x10, 0x30 };
+       unsigned char data = 0;
+       
+       for(i=3; i>=0; i--) {
+               outbyte(3, minor);
+               outbyte(i, minor);
+               for(j=0; j<delay; j++) data = inbyte(minor);
+               /*printk("Probing -> %i: 0x%02x 0x%02x\n", i, data & 0x30,
seq[i]);*/
+               if( (data & 0x30) != seq[i]) {
+                       outbyte(3, minor);
+                       return -1;
+               }
+       } 
+       outbyte(3, minor);
+       return 0;
+}
+
+/* ----- kernel module functions--------------------------------------- */
+
+static int tipar_open(struct inode *inode, struct file *file)
+{
+       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if(table[minor].opened)
+               return -EBUSY;
+
+       table[minor].opened++;
+
+       lp_claim_parport_or_block(table[minor].dev);
+       init_ti_parallel(minor);
+       lp_release_parport(table[minor].dev);
+
+       return 0;
+}
+
+static int tipar_close(struct inode *inode, struct file *file)
+{
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if(!table[minor].opened)
+               return -EFAULT;
+
+       table[minor].opened--;
+
+       return 0;
+}
+
+static ssize_t tipar_write(struct file *file,
+                          const char *buf, size_t count, loff_t *ppos)
+{
+       unsigned int minor = minor(file->f_dentry->d_inode->i_rdev) - 
+               TIPAR_MINOR_0;
+       ssize_t n;
+  
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if (table[minor].dev == NULL) 
+               return -ENXIO;
+
+       parport_claim_or_block (table[minor].dev);
+       
+       for(n=0; n<count; n++) {
+               unsigned char b;
+               
+               if(get_user(b, buf + n)) {
+                       n = -EFAULT;
+                       goto out;
+               }
+
+               if(put_ti_parallel(minor, b) == -1) {
+                       init_ti_parallel(minor);
+                       n = -ETIMEDOUT;
+                       goto out;
+               }
+       }
+
+ out:
+       parport_release (table[minor].dev);
+       return n;
+}
+
+static ssize_t tipar_read(struct file *file, char *buf, 
+                         size_t count, loff_t *ppos)
+{
+       int b=0;
+       unsigned int minor=minor(file->f_dentry->d_inode->i_rdev) - 
+               TIPAR_MINOR_0;
+       ssize_t retval = 0;
+
+       if(count == 0)
+               return 0;
+
+       if(ppos != &file->f_pos)
+               return -ESPIPE;
+
+       parport_claim_or_block(table[minor].dev);
+  
+       do {
+               b = get_ti_parallel(minor);
+               if(b == -1) {
+                       init_ti_parallel(minor);
+                       retval = -ETIMEDOUT;
+                       goto out;
+               }
+               else
+                       break;
+      
+               /* Non-blocking mode: try again ! */
+               if (file->f_flags & O_NONBLOCK) {
+                       retval = -EAGAIN;
+                       goto out;
+               }
+               
+               /* Signal pending, try again ! */
+               if (signal_pending(current)) {
+                       retval = -ERESTARTSYS;
+                       goto out;
+               }
+
+               schedule();
+       } while (1);
+
+       retval = put_user(b, (unsigned char *)buf);
+       if(!retval)
+               retval = 1;
+       else
+               retval = -EFAULT;
+
+ out:
+       parport_release(table[minor].dev);
+       return retval;
+}
+
+static int tipar_ioctl(struct inode *inode, struct file *file,
+                      unsigned int cmd, unsigned long arg)
+{
+       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+       int retval = 0;
+
+       if (minor >= PP_NO) 
+               return -ENODEV;
+
+       switch (cmd) {
+       case 0:
+               break;
+       case TIPAR_DELAY:
+               delay = arg;
+               return 0;
+       case TIPAR_TIMEOUT:
+               timeout = arg;
+               return 0;
+       default:
+               retval = -ENOTTY;
+               break;
+       }
+
+       return retval;
+}
+
+static long long tipar_lseek(struct file * file, long long offset, int origin)
+{
+       return -ESPIPE;
+}
+
+
+/* ----- kernel module registering ------------------------------------ */
+
+static struct file_operations tipar_fops = {
+       owner:   THIS_MODULE,
+       llseek:  no_llseek,
+       read:    tipar_read,
+       write:   tipar_write,
+       ioctl:   tipar_ioctl,
+       open:    tipar_open,
+       release: tipar_close,
+};
+
+/* --- initialisation code ------------------------------------- */
+
+#ifndef MODULE
+/*      You must set these - there is no sane way to probe for this cable.
+ *      You can use tipar=timeout,delay to set these now. */
+static int __init tipar_setup (char *str)
+{
+       int ints[2];
+
+        str = get_options (str, ARRAY_SIZE(ints), ints);
+
+        if (ints[0] > 0) {
+                timeout = ints[1];
+                if(ints[0] > 1) {
+                        delay = ints[2];
+               }
+        }
+        return 1;
+}
+#endif
+
+/*
+ * Register our module into parport.
+ * Pass also 2 callbacks functions to parport: a pre-emptive function and an
+ * interrupt handler function (unused).
+ * Display a message such "tipar0: using parport0 (polling)".
+ */
+static int tipar_register(int nr, struct parport *port)
+{
+       char name[8];
+       
+       /* Register our module into parport */
+       table[nr].dev = parport_register_device(port, "tipar",
+                                               NULL, NULL, NULL, 0,
+                                               (void *) &table[nr]);
+       
+       if (table[nr].dev == NULL)
+               return 1;
+ 
+       /* Use devfs, tree: /dev/ticables/par/[0..2] */
+       sprintf(name, "%d", nr);
+       devfs_register(devfs_handle, name,
+                       DEVFS_FL_AUTO_DEVNUM, TIPAR_MAJOR, nr,
+                       S_IFCHR | S_IRUGO | S_IWUGO,
+                       &tipar_fops, NULL);
+
+       /* Display informations */
+       printk(KERN_INFO "tipar%d: using %s (%s).\n", nr, port->name,
+              (port->irq == PARPORT_IRQ_NONE) ? "polling" :
"interrupt-driven");
+
+       if(probe_ti_parallel(nr) != -1)
+               printk("tipar%d: link cable found !\n", nr);
+       else
+               printk("tipar%d: link cable not found (do not plug cable to
calc).\n", nr);
+
+       return 0;
+}
+
+static void tipar_attach (struct parport *port)
+{
+       if (tp_count == PP_NO) {
+               printk("tipar: ignoring parallel port (max. %d)\n", 
+                      PP_NO);
+               return;
+       }
+       if (!tipar_register(tp_count, port))
+               tp_count++;
+}
+
+static void tipar_detach (struct parport *port)
+{
+       /* Will be written at some point in the future */
+}
+
+static struct parport_driver tipar_driver = {
+       "tipar",
+       tipar_attach,
+       tipar_detach,
+       NULL
+};
+
+int tipar_init(void)
+{
+       unsigned int i;
+       
+       /* Initialize structure */
+       for (i = 0; i < PP_NO; i++) {
+               table[i].dev = NULL;
+               table[i].opened = 0;
+       }
+
+       /* Register parport device */  
+       if (devfs_register_chrdev (TIPAR_MAJOR, "tipar", &tipar_fops)) {
+               printk("tipar: unable to get major %d\n", TIPAR_MAJOR);
+               return -EIO;
+       }
+
+       /* Use devfs with tree: /dev/ticables/par/[0..2] */
+       devfs_handle = devfs_mk_dir (NULL, "ticables/par", NULL);
+
+       if (parport_register_driver (&tipar_driver)) {
+               printk ("tipar: unable to register with parport\n");
+               return -EIO;
+       }
+
+       return 0;
+}  
+
+int __init tipar_init_module(void)
+{
+       printk("tipar: parallel link cable driver, version %s\n", VERSION);
+       return tipar_init();
+}
+
+void __exit tipar_cleanup_module(void)
+{
+       unsigned int offset;
+
+       /* Unregistering module */
+       parport_unregister_driver (&tipar_driver);
+
+       devfs_unregister (devfs_handle);
+       devfs_unregister_chrdev(TIPAR_MAJOR, "tipar");  
+
+       for (offset = 0; offset < PP_NO; offset++) {
+               if (table[offset].dev == NULL)
+                       continue;
+               parport_unregister_device(table[offset].dev);
+       }
+}
+
+__setup("tipar=", tipar_setup);
+module_init(tipar_init_module);
+module_exit(tipar_cleanup_module);
+
+MODULE_AUTHOR("Author/Maintainer: Romain Lievin <roms@lpg.ticalc.org>");
+MODULE_DESCRIPTION("Device driver for TI/PC parallel link cables");
+MODULE_LICENSE("GPL");
+
+EXPORT_NO_SYMBOLS;
+
+MODULE_PARM(timeout, "i");
+MODULE_PARM_DESC(timeout, "Timeout, default=1.5 seconds");
+MODULE_PARM(delay, "i");
+MODULE_PARM_DESC(delay, "Inter-bit delay, default=10 microseconds");
--- linux.orig/include/linux/ticable.h  Wed Mar 13 19:42:30 2002
+++ linux/include/linux/ticable.h       Wed Mar 13 21:25:03 2002
@@ -0,0 +1,41 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar/tiser/tiglusb - low level driver for handling link cables
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#ifndef TICABLE_H 
+#define TICABLE_H 1
+
+/* Internal default constants for the kernel module */
+#define TIMAXTIME 10      /* 1 seconds                         */
+#define IO_DELAY  10      /* 10 micro-seconds  */
+
+/* Major & minor number for character devices */
+#define TIPAR_MAJOR   61
+#define TIPAR_MINOR_0  1
+#define TIPAR_MINOR_1  2
+#define TIPAR_MINOR_2  3
+
+#define TISER_MAJOR   62
+#define TISER_MINOR_0  1
+#define TISER_MINOR_1  2
+#define TISER_MINOR_2  3
+#define TISER_MINOR_3  4
+
+/*
+ * Request values for the 'ioctl' function.
+ * Simply pass the appropriate value as arg of the ioctl call.
+ * These values do not conflict with other ones but they have to be
+ * allocated... (/usr/src/linux/Documentation/ioctl-number.txt).
+ */
+#define TIPAR_DELAY     _IOW('p', 0xa8, int) /* set delay   */
+#define TIPAR_TIMEOUT   _IOW('p', 0xa9, int) /* set timeout */
+
+#define TISER_DELAY     _IOW('p', 0xa0, int) /* set delay   */
+#define TISER_TIMEOUT   _IOW('p', 0xa1, int) /* set timeout */
+
+#endif /* TICABLE_H */


Romain.

---
Romain Liévin (aka roms)
http://lpg.ticalc.org/prj_tilp, prj_usb, prj_tidev, prj_gtktiemu
mail: roms@lpg.ticalc.org

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311365AbSCMUuD>; Wed, 13 Mar 2002 15:50:03 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311360AbSCMUty>; Wed, 13 Mar 2002 15:49:54 -0500
Received: from chaos.analogic.com ([204.178.40.224]:59011 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S311362AbSCMUtp> convert rfc822-to-8bit; Wed, 13 Mar 2002 15:49:45 -0500
Date: Wed, 13 Mar 2002 15:49:45 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: =?ISO-8859-1?Q?Romain_Li=E9vin?= <rlievin@free.fr>
cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <1016051318.3c8fb67699ae8@imp.free.fr>
Message-ID: <Pine.LNX.3.95.1020313153432.30430A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 13 Mar 2002, [ISO-8859-1] Romain Liévin wrote:
I'm going to comment on a few points:

[SNIPPED most...]

> +
> +/* D-bus protocol:
> +                    1                 0                      0
> +       _______        ______|______    __________|________    __________
> +Red  :        ________      |      ____          |        ____
> +       _        ____________|________      ______|__________       _____
> +White:  ________            |        ______      |          _______
> +*/
> +
> +/* Try to transmit a byte on the specified port (-1 if error). */
> +static int put_ti_parallel(int minor, unsigned char data)
> +{
> +       int bit, i;
> +       unsigned long max;
> +  
> +       for (bit=0; bit<8; bit++) {
> +               if (data & 1) {
> +                       outbyte(2, minor);
> +                       START(max); 
> +                       do {
> +                               WAIT(max);
> +                       } while (inbyte(minor) & 0x10);

             This may never happen. You end up waiting forever!
             If the port doesn't exist or is broken, it may return 0xff
             forever! You need to time-out and get out.


> +                       
> +                       outbyte(3, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x10));

                     This may never happen. You end up awiting forever!
                     You need to time-out and get out.


> +               } else {
> +                       outbyte(1, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (inbyte(minor) & 0x20);
> +                       
                       This also may never happen!
                       Same applies, time-out and get out.
                     
> +                       outbyte(3, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x20));

                      This also may never happen!
                      Same applives, time-out and get out.

> +               }
> +               data >>= 1;
> +               for(i=0; i < delay; i++) {
> +                       inbyte(minor);
> +               }

> +               schedule();

                  This will just spin without setting
                  current->policy |= SCHED_YIELD;
                  (you really should use sys_sched_yield())


> +       }
> +       
> +       return 0;
> +}
> +
> +/* Receive a byte on the specified port or -1 if error. */
> +static int get_ti_parallel(int minor)
> +{
> +       int bit,i;
> +       unsigned char v, data=0;
> +       unsigned long max;
> +
> +       for (bit=0; bit<8; bit++) {
> +               START(max); 
> +               do {
> +                       WAIT(max);
> +               } while ((v=inbyte(minor) & 0x30) == 0x30);
> +      
                  More wait-forever above...

> +               if (v == 0x10) { 
> +                       data=(data>>1) | 0x80;
> +                       outbyte(1, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x20));

                      More wait-forever above.


> +                       outbyte(3, minor);
> +               } else {
> +                       data=data>>1;
> +                       outbyte(2, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x10));
> +                       outbyte(3, minor);
                      More wait-forever!

> +               }
> +               for(i=0; i<delay; i++) {
> +                       inbyte(minor);
> +               }
> +               schedule();
                  No current->policy

> +       }
> +       return (int)data;
> +}
> +

[SNIPPED rest]


Basically, this code performs a needed function. I have been waiting
for someone to write this! However, it's not yet ready for prime-time.
Never assume that hardware is going to produce what you expect. Don't
wait forever for something that was supposed to happen. You'll hang
the machine.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311402AbSCMWM1>; Wed, 13 Mar 2002 17:12:27 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311398AbSCMWMP>; Wed, 13 Mar 2002 17:12:15 -0500
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:62727 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S311399AbSCMWL7>; Wed, 13 Mar 2002 17:11:59 -0500
Subject: Re: your mail
To: root@chaos.analogic.com
Date: Wed, 13 Mar 2002 22:27:35 +0000 (GMT)
Cc: rlievin@free.fr (=?ISO-8859-1?Q?Romain_Li=E9vin?=),
        alan@lxorguk.ukuu.org.uk (Alan Cox),
        linux-kernel@vger.kernel.org (Kernel List)
In-Reply-To: <Pine.LNX.3.95.1020313153432.30430A-100000@chaos.analogic.com> from "Richard B. Johnson" at Mar 13, 2002 03:49:45 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16lHDb-0007cX-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > +                       START(max);=20
> > +                       do {
> > +                               WAIT(max);
> > +                       } while (inbyte(minor) & 0x10);
> 
>              This may never happen. You end up waiting forever!

No - its hidden in his macros. Look harder



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311403AbSCMWTu>; Wed, 13 Mar 2002 17:19:50 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311404AbSCMWTh>; Wed, 13 Mar 2002 17:19:37 -0500
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:5384 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S311403AbSCMWTX>; Wed, 13 Mar 2002 17:19:23 -0500
Subject: Re: your mail
To: rlievin@free.fr (=?ISO-8859-1?Q?Romain_Li=E9vin?=)
Date: Wed, 13 Mar 2002 22:35:07 +0000 (GMT)
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox),
        linux-kernel@vger.kernel.org (Kernel List)
In-Reply-To: <1016051318.3c8fb67699ae8@imp.free.fr> from "=?ISO-8859-1?Q?Romain_Li=E9vin?=" at Mar 13, 2002 09:28:38 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16lHKt-0007dn-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> +/*
> + * Deal with CONFIG_MODVERSIONS
> + */
> +#if 0 /* Pb with MODVERSIONS */
> +#if CONFIG_MODVERSIONS==1
> +#define MODVERSIONS
> +#include <linux/modversions.h>
> +#endif
> +#endif

[modversions.h is magically included by the kernel for you when its in 
 kernel if you haven't worked that one out yet]

> +#define PP_NO 3
> +struct tipar_struct  table[PP_NO];
static ?

> +               for(i=0; i < delay; i++) {
> +                       inbyte(minor);
> +               }
> +               schedule();

Oh random tip

		  if(current->need_resched)
			schedule();

will just give up the CPU when you are out of time

> +       if(table[minor].opened)
> +               return -EBUSY;
> +       table[minor].opened++;

Think about open/close at the same moment or SMP - the watchdog drivers all
had this problem and now do

	unsigned long opened = 0;

	if(test_and_set_bit(0, &opened))
		return -EBUSY;

	clear_bit(0, &opened)

[this generates atomic operations so is always safe]

> +       if(!table[minor].opened)
> +               return -EFAULT;

	BUG() may be better - it can't happen so BUG() will get a backtrace
and actually get it reported 8)

> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> +       return -ESPIPE;
> +}

Can go (you now use no_llseek)


Basically except for the open/close one I'm now just picking holes. 
For the device major/minors see http://www.lanana.org.




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S292535AbSCNHZP>; Thu, 14 Mar 2002 02:25:15 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S310743AbSCNHZF>; Thu, 14 Mar 2002 02:25:05 -0500
Received: from swazi.realnet.co.sz ([196.28.7.2]:11162 "HELO
	netfinity.realnet.co.sz") by vger.kernel.org with SMTP
	id <S292535AbSCNHYt>; Thu, 14 Mar 2002 02:24:49 -0500
Date: Thu, 14 Mar 2002 09:08:23 +0200 (SAST)
From: Zwane Mwaikambo <zwane@linux.realnet.co.sz>
X-X-Sender: zwane@netfinity.realnet.co.sz
To: =?ISO-8859-1?Q?Romain_Li=E9vin?= <rlievin@free.fr>
Cc: Kernel List <linux-kernel@vger.kernel.org>,
        Alan Cox <alan@lxorguk.ukuu.org.uk>, Tim Waugh <tim@cyberelk.net>
Subject: Re: your mail
In-Reply-To: <1016047267.3c8fa6a3660e3@imp3-1.free.fr>
Message-ID: <Pine.LNX.4.44.0203140906330.3868-100000@netfinity.realnet.co.sz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Firstly, thanks for doing this =) secondly i'll give your driver a try 
when you release the serial version (i have a serial cable + TI-83)

Cheers,
	Zwane



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S313930AbSDUXC4>; Sun, 21 Apr 2002 19:02:56 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S313933AbSDUXC4>; Sun, 21 Apr 2002 19:02:56 -0400
Received: from panic.tn.gatech.edu ([130.207.137.62]:1970 "HELO gtf.org")
	by vger.kernel.org with SMTP id <S313930AbSDUXCz>;
	Sun, 21 Apr 2002 19:02:55 -0400
Date: Sun, 21 Apr 2002 19:02:55 -0400
From: Jeff Garzik <garzik@havoc.gtf.org>
To: "Ivan G." <ivangurdiev@yahoo.com>
Cc: Urban Widmark <urban@teststation.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20020421190255.B22314@havoc.gtf.org>
In-Reply-To: <02042115164004.00745@cobra.linux>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 21, 2002 at 03:16:40PM -0600, Ivan G. wrote:
> Urban,
> 
> About the suggestion to make via_rhine_error handle more interrupts,
> 
> enum intr_status_bits {
>         IntrRxDone=0x0001, IntrRxErr=0x0004, IntrRxEmpty=0x0020,
>         IntrTxDone=0x0002, IntrTxAbort=0x0008, IntrTxUnderrun=0x0010,
>         IntrPCIErr=0x0040,
>         IntrStatsMax=0x0080, IntrRxEarly=0x0100, IntrMIIChange=0x0200,
>         IntrRxOverflow=0x0400, IntrRxDropped=0x0800, IntrRxNoBuf=0x1000,
>         IntrTxAborted=0x2000, IntrLinkChange=0x4000,
>         IntrRxWakeUp=0x8000,
>         IntrNormalSummary=0x0003, IntrAbnormalSummary=0xC260,
> };
> 
> RxEarly, RxOverflow, RxNoBuf are not handled
> (which brings up another question - how should they be handled 
> and where?? It doesn't seem to me that those should end up in error,
> sending CmdTxDemand. )

*blink*  I had not noticed that.

All drivers actually need to handle RxNoBufs and RxOverflow, assuming
they have similar meaning to what I'm familiar with on other chips.
The chip may recover transparently, but one should be at least aware of
them.

RxEarly you very likely do -not- want to handle...

	Jeff





From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S292855AbSDXIJE>; Wed, 24 Apr 2002 04:09:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S292857AbSDXIJD>; Wed, 24 Apr 2002 04:09:03 -0400
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:24842 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S292855AbSDXIJD>; Wed, 24 Apr 2002 04:09:03 -0400
Subject: Re: your mail
To: zghuo@gatekeeper.ncic.ac.cn (Huo Zhigang)
Date: Wed, 24 Apr 2002 09:27:27 +0100 (BST)
Cc: linux-kernel@vger.kernel.org (linux-kernel@vger.kernel.org)
In-Reply-To: <7754BE2716BF.AAAE8A@gatekeeper.ncic.ac.cn> from "Huo Zhigang" at Apr 24, 2002 03:55:25 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E170I7b-000254-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> 
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>   
>   What's wrong with my machines?  They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
>   Thank you in advance 8-)

If you boot the machije without your driver, then reboot does the
same happen ? If not then it may well be your driver has an error but only
when it closes down

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S292857AbSDXI2g>; Wed, 24 Apr 2002 04:28:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293048AbSDXI2f>; Wed, 24 Apr 2002 04:28:35 -0400
Received: from swazi.realnet.co.sz ([196.28.7.2]:11393 "HELO
	netfinity.realnet.co.sz") by vger.kernel.org with SMTP
	id <S292857AbSDXI2f>; Wed, 24 Apr 2002 04:28:35 -0400
Date: Wed, 24 Apr 2002 09:51:21 +0200 (SAST)
From: Zwane Mwaikambo <zwane@linux.realnet.co.sz>
X-X-Sender: zwane@netfinity.realnet.co.sz
To: Huo Zhigang <zghuo@gatekeeper.ncic.ac.cn>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <7754BE2716BF.AAAE8A@gatekeeper.ncic.ac.cn>
Message-ID: <Pine.LNX.4.44.0204240949340.3320-100000@netfinity.realnet.co.sz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 24 Apr 2002, Huo Zhigang wrote:

>   Hi, all.
>   My cluster go wrong these days. So many times when I "/sbin/reboot" a node, the following message will be displayed on the console.
> 
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>   
>   What's wrong with my machines?  They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
>   Thank you in advance 8-)
>   
>             Zhigang Huo
>             zghuo@ncic.ac.cn

Have you tried decoding the oops? Have a look at  
linux/Documentation/oops-tracing.txt

	Zwane

-- 
http://function.linuxpower.ca



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S313715AbSECOiC>; Fri, 3 May 2002 10:38:02 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S313724AbSECOiB>; Fri, 3 May 2002 10:38:01 -0400
Received: from louise.pinerecords.com ([212.71.160.16]:12296 "EHLO
	louise.pinerecords.com") by vger.kernel.org with ESMTP
	id <S313715AbSECOiA>; Fri, 3 May 2002 10:38:00 -0400
Date: Fri, 3 May 2002 16:37:38 +0200
From: tomas szepe <kala@pinerecords.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020503143738.GC14121@louise.pinerecords.com>
In-Reply-To: <13468.1020435550@ocs3.intra.ocs.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-OS: Linux/sparc 2.2.21-rc3-ext3-0.0.7a SMP (up 11 days, 7:27)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> release 2.4.
>
> kbuild-2.5-core-13-1.

I believe you meant 's/13/10/'.

> kbuild-2.5-common-2.5.13-1.
> kbuild-2.5-i386-2.5.13-1.

hmmm.. doesn't look so good.

kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
kala@nibbler:~$ cd linux-2.5.13 
kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
...

kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
spec value %p not found
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
  phase 2 (convert all Makefile.in files)
  phase 3 (evaluate selections)
  phase 4 (integrity checks, write global makefile)
pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
make: *** [phase4] Error 1


T.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314223AbSECPID>; Fri, 3 May 2002 11:08:03 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314274AbSECPIC>; Fri, 3 May 2002 11:08:02 -0400
Received: from louise.pinerecords.com ([212.71.160.16]:32520 "EHLO
	louise.pinerecords.com") by vger.kernel.org with ESMTP
	id <S314223AbSECPIA>; Fri, 3 May 2002 11:08:00 -0400
Date: Fri, 3 May 2002 17:07:31 +0200
From: tomas szepe <kala@pinerecords.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020503150731.GA15883@louise.pinerecords.com>
In-Reply-To: <13468.1020435550@ocs3.intra.ocs.com.au> <20020503143738.GC14121@louise.pinerecords.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-OS: Linux/sparc 2.2.21-rc3-ext3-0.0.7a SMP (up 11 days, 9:32)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Building as follows works, though.

$ cd /usr/src && tar xzf linux-2.5.13.tar.gz
$ cd ~ && mkdir build && cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
$ M installable

T.


> > Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> > http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> > release 2.4.
> >
> > kbuild-2.5-core-13-1.
> 
> I believe you meant 's/13/10/'.
> 
> > kbuild-2.5-common-2.5.13-1.
> > kbuild-2.5-i386-2.5.13-1.
> 
> hmmm.. doesn't look so good.
> 
> kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
> kala@nibbler:~$ cd linux-2.5.13 
> kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
>   phase 1 (find all inputs)
> ...
> 
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> spec value %p not found
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
>   phase 1 (find all inputs)
>   phase 2 (convert all Makefile.in files)
>   phase 3 (evaluate selections)
>   phase 4 (integrity checks, write global makefile)
> pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
> make: *** [phase4] Error 1
> 
> 
> T.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314328AbSECPaB>; Fri, 3 May 2002 11:30:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314330AbSECPaA>; Fri, 3 May 2002 11:30:00 -0400
Received: from mail.ocs.com.au ([203.34.97.2]:17677 "HELO mail.ocs.com.au")
	by vger.kernel.org with SMTP id <S314328AbSECPaA>;
	Fri, 3 May 2002 11:30:00 -0400
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@ocs.com.au>
To: tomas szepe <kala@pinerecords.com>
Cc: kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-Reply-To: Your message of "Fri, 03 May 2002 16:37:38 +0200."
             <20020503143738.GC14121@louise.pinerecords.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 04 May 2002 01:29:46 +1000
Message-ID: <14454.1020439786@ocs3.intra.ocs.com.au>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 3 May 2002 16:37:38 +0200, 
tomas szepe <kala@pinerecords.com> wrote:
>kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
>kala@nibbler:~$ cd linux-2.5.13 
>kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
>kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
>kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
>Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory

The trailing '/' is omitted in one case.  Workaround for common source and object

export KBUILD_SRCTREE_000=`pwd`/
make -f Makefile-2.5 oldconfig


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314465AbSECPq1>; Fri, 3 May 2002 11:46:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314469AbSECPq0>; Fri, 3 May 2002 11:46:26 -0400
Received: from louise.pinerecords.com ([212.71.160.16]:57608 "EHLO
	louise.pinerecords.com") by vger.kernel.org with ESMTP
	id <S314465AbSECPqZ>; Fri, 3 May 2002 11:46:25 -0400
Date: Fri, 3 May 2002 17:45:54 +0200
From: tomas szepe <kala@pinerecords.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: kbuild-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020503154554.GB15883@louise.pinerecords.com>
In-Reply-To: <20020503143738.GC14121@louise.pinerecords.com> <14454.1020439786@ocs3.intra.ocs.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-OS: Linux/sparc 2.2.21-rc3-ext3-0.0.7a SMP (up 11 days, 9:32)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> On Fri, 3 May 2002 16:37:38 +0200, 
> tomas szepe <kala@pinerecords.com> wrote:
>
> >kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
> >kala@nibbler:~$ cd linux-2.5.13 
> >kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> >kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> >kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> >Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> 
> The trailing '/' is omitted in one case.  Workaround for common source and object
> 
> export KBUILD_SRCTREE_000=`pwd`/
> make -f Makefile-2.5 oldconfig

Another problem/question:

$ cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
...

$ M installable
...

[so far so good]

$ make -f Makefile-2.5 menuconfig
[enable RAMDISK support, tweak ramdisk size, enable initrd]
...

Now, issuing "M installable" will result in nearly all files getting rebuilt.
The same happens when switching ramdisk off again. How's that?

I tried enabling/disabling many other config options and doing rebuilds but
couldn't find anything as damaging buildtime-wise as the ramdisk stuff.

Hopefully I'm causing no headaches,
T.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S312590AbSEPNYU>; Thu, 16 May 2002 09:24:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S312600AbSEPNYT>; Thu, 16 May 2002 09:24:19 -0400
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:35598 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S312590AbSEPNYS>; Thu, 16 May 2002 09:24:18 -0400
Subject: Re: your mail
To: sanket.rathi@cdac.ernet.in (Sanket Rathi)
Date: Thu, 16 May 2002 14:38:05 +0100 (BST)
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <Pine.GSO.4.10.10205161809140.1835-100000@mailhub.cdac.ernet.in> from "Sanket Rathi" at May 16, 2002 06:10:05 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E178LSH-0004GU-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I just want to know how can we restrict the maximum virtual memory and
> maximum physical memory on ia64 platform.
> kernel. Actually we have a device which can only access 44 bits so we cant

That won't help you. You might not be dealing with RAM at the bottom of the
address space. You might also be in platforms with an iommu, or doing DMA
to another PCI target

> Tell me something related to this or any link which i can refer

Assuming the device is doing bus mastering. Read
Documentation/DMA-mapping.txt

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S313416AbSEPP4L>; Thu, 16 May 2002 11:56:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S313477AbSEPP4L>; Thu, 16 May 2002 11:56:11 -0400
Received: from mailx.cdacindia.com ([202.54.40.35]:60337 "EHLO
	falcon.cdac.ernet.in") by vger.kernel.org with ESMTP
	id <S313416AbSEPP4K>; Thu, 16 May 2002 11:56:10 -0400
Date: Thu, 16 May 2002 21:24:10 +0530 (IST)
From: Sanket Rathi <sanket.rathi@cdac.ernet.in>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: Sanket Rathi <sanket.rathi@cdac.ernet.in>, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <E178LSH-0004GU-00@the-village.bc.nu>
Message-ID: <Pine.GSO.4.10.10205162118380.10635-100000@mailhub.cdac.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

No actually i don't want that for DMA it is for diffrent requirment.
actually in our device there is a page table in device which have
virtual to physical address translation we save virtual address in device
and corresponding physical address. but we can store only upto 44 bit 
information of virtual address thats why i want that.

Can you help me in this 

Thanks in advance

-----
--------Sanket


> > I just want to know how can we restrict the maximum virtual memory and
> > maximum physical memory on ia64 platform.
> > kernel. Actually we have a device which can only access 44 bits so we cant
> 
> That won't help you. You might not be dealing with RAM at the bottom of the
> address space. You might also be in platforms with an iommu, or doing DMA
> to another PCI target
> 
> > Tell me something related to this or any link which i can refer
> 
> Assuming the device is doing bus mastering. Read
> Documentation/DMA-mapping.txt
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314471AbSEPRql>; Thu, 16 May 2002 13:46:41 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314484AbSEPRqk>; Thu, 16 May 2002 13:46:40 -0400
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:31505 "EHLO
	the-village.bc.nu") by vger.kernel.org with ESMTP
	id <S314471AbSEPRqk>; Thu, 16 May 2002 13:46:40 -0400
Subject: Re: your mail
To: sanket.rathi@cdac.ernet.in (Sanket Rathi)
Date: Thu, 16 May 2002 19:05:43 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox),
        sanket.rathi@cdac.ernet.in (Sanket Rathi),
        linux-kernel@vger.kernel.org
In-Reply-To: <Pine.GSO.4.10.10205162118380.10635-100000@mailhub.cdac.ernet.in> from "Sanket Rathi" at May 16, 2002 09:24:10 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E178PdH-0004kE-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> No actually i don't want that for DMA it is for diffrent requirment.
> actually in our device there is a page table in device which have
> virtual to physical address translation we save virtual address in device
> and corresponding physical address. but we can store only upto 44 bit 
> information of virtual address thats why i want that.

Still read Documentation/DMA-mapping.txt

Whether its DMA or not you are going to need to keep the allocations below
44bits and thats what the DMA allocators do

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S316181AbSETSHm>; Mon, 20 May 2002 14:07:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S316182AbSETSHl>; Mon, 20 May 2002 14:07:41 -0400
Received: from deimos.hpl.hp.com ([192.6.19.190]:992 "EHLO deimos.hpl.hp.com")
	by vger.kernel.org with ESMTP id <S316181AbSETSHk>;
	Mon, 20 May 2002 14:07:40 -0400
From: David Mosberger <davidm@napali.hpl.hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15593.15196.98387.461937@napali.hpl.hp.com>
Date: Mon, 20 May 2002 11:07:24 -0700
To: Sanket Rathi <sanket.rathi@cdac.ernet.in>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Pine.GSO.4.10.10205162118380.10635-100000@mailhub.cdac.ernet.in>
X-Mailer: VM 7.03 under Emacs 21.1.1
Reply-To: davidm@hpl.hp.com
X-URL: http://www.hpl.hp.com/personal/David_Mosberger/
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>>>>> On Thu, 16 May 2002 21:24:10 +0530 (IST), Sanket Rathi <sanket.rathi@cdac.ernet.in> said:

  Sanket> No actually i don't want that for DMA it is for diffrent
  Sanket> requirment.  actually in our device there is a page table in
  Sanket> device which have virtual to physical address translation we
  Sanket> save virtual address in device and corresponding physical
  Sanket> address. but we can store only upto 44 bit information of
  Sanket> virtual address thats why i want that.

  Sanket> Can you help me in this

There is no way to limit virtual memory to 44 bits.  I don't know how
your device works, but just fyi: ia64 divides the address space into 8
equal-sized regions and user space applications tend to use at least
two regions (2 for text and 3 for data/stack).  This means that even
with the smallest page size, you'll have to take virtual address bits
61-63 into account.

Hope this helps,

	--david
--
Interested in learning more about IA-64 Linux?  Try http://www.lia64.org/book/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S311752AbSFXJL7>; Mon, 24 Jun 2002 05:11:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S311898AbSFXJL6>; Mon, 24 Jun 2002 05:11:58 -0400
Received: from www.rulehinge.com ([196.28.7.66]:64425 "HELO
	netfinity.realnet.co.sz") by vger.kernel.org with SMTP
	id <S310190AbSFXJL5>; Mon, 24 Jun 2002 05:11:57 -0400
Date: Mon, 24 Jun 2002 09:34:15 +0200 (SAST)
From: Zwane Mwaikambo <zwane@linux.realnet.co.sz>
X-X-Sender: zwane@netfinity.realnet.co.sz
To: pah@promiscua.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20020624054959.19187.qmail@promiscua.org>
Message-ID: <Pine.LNX.4.44.0206240932220.2603-100000@netfinity.realnet.co.sz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 24 Jun 2002 pah@promiscua.org wrote:

> 	I've just found a bug (an unsignificant bug) in the panic() function!
> 	There's a possible buffer overflow if the formated string exceeds
> 1024 characters (I think that the problem is in all kernel releases).
> 	The problem is in the use of vsprintf() insted of vsnprintf()!
> 
> 	I know that this doesn't compromise any exploitation by an uid
> different than zero, but should be fixed in the case of panic()'s arguments
> exceeds the buffer limit (probably by an lkm or something like that) and
> cause (probably) a system crash.
> 

In that case there are quite a number of other places in the kernel which 
can be 'exploited' in various ways.

Cheers,
	Zwane

--
http://function.linuxpower.ca
		


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314529AbSGDWDR>; Thu, 4 Jul 2002 18:03:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314546AbSGDWDQ>; Thu, 4 Jul 2002 18:03:16 -0400
Received: from nat-pool-rdu.redhat.com ([66.187.233.200]:65111 "EHLO
	devserv.devel.redhat.com") by vger.kernel.org with ESMTP
	id <S314529AbSGDWDP>; Thu, 4 Jul 2002 18:03:15 -0400
Date: Thu, 4 Jul 2002 21:45:21 +0100
From: Stephen Tweedie <sct@redhat.com>
To: Naseer Bhatti <naseer@digitallinx.com>
Cc: security@proftpd.org, security@apache.org, linux-kernel@vger.kernel.org,
       sct@redhat.com, akpm@zip.com.au, adilger@turbolinux.com,
       ext3-users@redhat.com
Subject: Re: your mail
Message-ID: <20020704214521.D27198@redhat.com>
References: <000d01c22361$62c9d6f0$0100a8c0@digital>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <000d01c22361$62c9d6f0$0100a8c0@digital>; from naseer@digitallinx.com on Thu, Jul 04, 2002 at 06:47:11PM +0500
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On Thu, Jul 04, 2002 at 06:47:11PM +0500, Naseer Bhatti <naseer@digitallinx.com> wrote:

> I got these errors in the log on a Production server. I am running ProFTPD 1.2.4 with RedHat 7.2 Kernel 2.4.7-10 not yet compiled myself and Apache 1.3.26. I got my server stop responding and after reboot I checked the logs and got a lots of kernel bugs. ProFTPD was also involved in that. httpd (Apache 1.3.26) also gave some stack output. Correct me if I am wrong. I have attached the file for detailed analysis. Please check it and let me know about the possible bug/solution.

The log shows no sign of any ext3 problem.  I can't see anything in it
which would justify trying to send a compressed log of nearly 400kB to
an ext3 general users mailing list.

For what it's worth, your dcache oopses are most often associated with
bad memory --- try memtest86 on that machine before you go any
further.

--Stephen

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S317444AbSGENcJ>; Fri, 5 Jul 2002 09:32:09 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S317446AbSGENcI>; Fri, 5 Jul 2002 09:32:08 -0400
Received: from h209-71-227-55.gtconnect.net ([209.71.227.55]:54790 "HELO
	innerfire.net") by vger.kernel.org with SMTP id <S317444AbSGENcH>;
	Fri, 5 Jul 2002 09:32:07 -0400
Date: Fri, 5 Jul 2002 09:34:41 -0400 (EDT)
From: Gerhard Mack <gmack@innerfire.net>
To: Christian Berger <christian@berger-online.de>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <1025858852.1154.0.camel@Rechner1.berger-online.de>
Message-ID: <Pine.LNX.4.44.0207050934160.29244-100000@innerfire.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Right command wrong email address.  You need to send that to
majordomo@vger.kernel.org



On 5 Jul 2002, Christian Berger wrote:

> Date: 05 Jul 2002 10:47:32 +0200
> From: Christian Berger <christian@berger-online.de>
> To: linux-kernel@vger.kernel.org
>
> unsubscribe linux-kernel
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S316503AbSGGT33>; Sun, 7 Jul 2002 15:29:29 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S316512AbSGGT33>; Sun, 7 Jul 2002 15:29:29 -0400
Received: from expert.cc.purdue.edu ([128.210.10.11]:12968 "EHLO
	expert.cc.purdue.edu") by vger.kernel.org with ESMTP
	id <S316503AbSGGT32>; Sun, 7 Jul 2002 15:29:28 -0400
Date: Sun, 7 Jul 2002 14:32:01 -0500 (EST)
From: Min Li <li9@expert.cc.purdue.edu>
To: Hacksaw <hacksaw@hacksaw.org>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <200207061559.g66Fxjh28040@habitrail.home.fools-errant.com>
Message-ID: <Pine.GSO.3.96.1020707143053.29468D-100000@expert.cc.purdue.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello, Yes, I tried to subcribe to those two lists. But I don't think they
are working. But I do need help right now...


On Sat, 6 Jul 2002, Hacksaw wrote:

> Hello Min:
> 
> I suggest your questions would be better asked on the kernle newbies list:
> http://mail.nl.linux.org/kernelnewbies/
> 
> and/or on the RedHat install List:
> 
> https://listman.redhat.com/mailman/listinfo/redhat-install-list.
> 
> The kernel list is strictly for talk about developing the kernel. Also, please 
> read the linux kernel mailing list FAQ: http://www.tux.org/lkml/
> -- 
> Powered by beta particles
> http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
> 
> 
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S318277AbSHPJsj>; Fri, 16 Aug 2002 05:48:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S318281AbSHPJsj>; Fri, 16 Aug 2002 05:48:39 -0400
Received: from willy.net1.nerim.net ([62.212.114.60]:31498 "EHLO
	www.home.local") by vger.kernel.org with ESMTP id <S318277AbSHPJsi>;
	Fri, 16 Aug 2002 05:48:38 -0400
Date: Fri, 16 Aug 2002 11:52:30 +0200
From: Willy Tarreau <willy@w.ods.org>
To: Misha Alex <misha_zant@hotmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020816095230.GA14227@alpha.home.local>
References: <F159156pqkw3Wctbnyd0000b29b@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F159156pqkw3Wctbnyd0000b29b@hotmail.com>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello !

On Fri, Aug 16, 2002 at 07:51:37AM +0000, Misha Alex wrote:
 
>      Also i tried the linear addressing linear = c*H*S + h*S +s -1 .But 
> linear or linear*512 never gave me the exact byte offset to seek.
> 
> I am working in linux and using a hexeditor to seek .How many exact bytes 
> should i seek to find out the extended partition.I read the MBR and found 
> the exteneded partiton.
> 00 01 01 00 02 fe 3f 01 3f 00 00 00 43 7d 00 00
> 80 00 01 02 0b fe bf 7e 82 7d 00 00 3d 26 9c 00
> 00 00 81 7f 0f fe ff ff bf a3 9c 00 f1 49 c3 01
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I haven't played with this for a long time, but I still have some memory
about this. First, when an offset is higher than 8GB, there's no way to
code it with the bios' CHS scheme as you find it in the partition table.
I see that you know how to decode this, so set all the CHS bits to ones
and look at the offset. For this reason, we often use only the size to
locate these partitions. If I recall correctly, the last 4 bytes of your
parts are the sizes in sectors. For example, hda2 is 9c263d sectors long,
which equals 5.2 GB. You'll notice that bytes 8 to 11 of each partitions
are nearly equivalent to the size of the previous part. They should be
the start offset in sectors. So in this case, hda3 begins at 9ca3bf
(byte 5255953920), and is 1c349f1 sectors long (15.1 GB).

I think that 'fe ff ff' after the partition type indicates that only the
linear mode should be used, but I'm not sure about this nor I do I have
any proof. You should read the partition code to get more clues, IMHO.

Hoping this helps,
Willy


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S313190AbSHTGnJ>; Tue, 20 Aug 2002 02:43:09 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S315372AbSHTGnJ>; Tue, 20 Aug 2002 02:43:09 -0400
Received: from einstein.kowalk.Informatik.Uni-Oldenburg.de ([134.106.55.1]:52611
	"EHLO walker.pmhahn.de") by vger.kernel.org with ESMTP
	id <S313190AbSHTGnJ>; Tue, 20 Aug 2002 02:43:09 -0400
Date: Tue, 20 Aug 2002 08:47:04 +0200
From: Philipp Matthias Hahn <pmhahn@titan.lahn.de>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020820064704.GA12845@titan.lahn.de>
Mail-Followup-To: Philipp Matthias Hahn <pmhahn@titan.lahn.de>,
	"Bloch, Jack" <Jack.Bloch@icn.siemens.com>,
	linux-kernel@vger.kernel.org
References: <180577A42806D61189D30008C7E632E87939F8@boca213a.boca.ssc.siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <180577A42806D61189D30008C7E632E87939F8@boca213a.boca.ssc.siemens.com>
User-Agent: Mutt/1.4i
Organization: UUCP-Freunde Lahn e.V.
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Jack!

On Mon, Aug 19, 2002 at 05:29:26PM -0400, Bloch, Jack wrote:
> Are there any plans to do an SCTP (RFC 2960) implementation for Linux?
> Please CC me directly on any responses.

The Linux Kernel 2.5 Status page at
	http://www.kernelnewbies.org/status/latest.html
lists the following URL:
	http://www.sf.net/projects/lksctp

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S318856AbSHWPIR>; Fri, 23 Aug 2002 11:08:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S318838AbSHWPIR>; Fri, 23 Aug 2002 11:08:17 -0400
Received: from string.physics.ubc.ca ([142.103.234.11]:47273 "HELO
	string.physics.ubc.ca") by vger.kernel.org with SMTP
	id <S318853AbSHWPIO>; Fri, 23 Aug 2002 11:08:14 -0400
Date: Fri, 23 Aug 2002 08:12:24 -0700 (PDT)
From: Bill Unruh <unruh@physics.ubc.ca>
To: Mike Dresser <mdresser_l@windsormachine.com>
Cc: <linux-ppp@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0208231029040.8320-100000@router.windsormachine.com>
Message-ID: <Pine.LNX.4.33L2.0208230806050.16223-100000@string.physics.ubc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Well, it would be good if you actually told us what problem you were
describing. Is this a new connection attempt after the first hang up?
What?

What repeats over and over-- I see no repeat.

You also do not tell us info like what kind of modem is this-- external,
internal, serial, usb, pci, winmodem,....

I assume what you are refering to is the "inappropriate ioctl" line.
This indicates a hardware problem.

Actually, it looks to me like another pppd is up on the line. Those
EchoReq are another pppd receiving stuff on an open pppd on another
line. More information on what it is you are trying to do, on what your
system is, and what the problem is might get you help.


On Fri, 23 Aug 2002, Mike Dresser wrote:

> I'm having problems with pppd under 2.4.19, with pppd 2.4.1
>
> I can establish a new connection, and no problems.  But once the ISP on
> the other end hangs up, this is what i get in my syslog.
> Repeats over and over.  I saw a few google postings about this, but those
> were back in _1999_, so I would think they were fixed by now.
>
> Doesn't matter if PPP is compiled in with the kernel, or modules.
>
> I'm running Debian 3.0(woody)
>
> This worked under Debian 2.2 and kernel 2.2.21
>
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (BUSY)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO CARRIER)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (VOICE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIALTONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIAL TONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO ANSWER)
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATZ^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (OK)
> Aug 23 10:25:55 tilburybackup chat[9825]: ATZ^M^M
> Aug 23 10:25:55 tilburybackup chat[9825]: OK
> Aug 23 10:25:55 tilburybackup chat[9825]:  -- got it
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATDT3806600^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (CONNECT)
> Aug 23 10:25:55 tilburybackup chat[9825]: ^M
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoReq id=0x4 magic=0x96835d5b]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoRep id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoReq id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoRep id=0x4 magic=0x96835d5b]
> Aug 23 10:26:16 tilburybackup chat[9825]: ATDT3806600^M^M
> Aug 23 10:26:16 tilburybackup chat[9825]: CONNECT
> Aug 23 10:26:16 tilburybackup chat[9825]:  -- got it
> Aug 23 10:26:16 tilburybackup chat[9825]: send (\d)
> Aug 23 10:26:17 tilburybackup pppd[329]: Serial connection established.
> Aug 23 10:26:17 tilburybackup pppd[329]: using channel 1179
> Aug 23 10:26:17 tilburybackup pppd[329]: Couldn't create new ppp unit: Inappropriate ioctl for device
> Aug 23 10:26:18 tilburybackup pppd[329]: Hangup (SIGHUP)
>
> tilburybackup:/etc/ppp# egrep -v '#|^ *$' /etc/ppp/options
> asyncmap 0
> auth
> crtscts
> lock
> hide-password
> modem
> proxyarp
> lcp-echo-interval 30
> lcp-echo-failure 4
> noipx
> persist
> maxfail 0
>
> ttyS04 at port 0xcc00 (irq = 5) is a 16550A
>
> 00:0b.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) (prog-if 02 [16550])
>         Subsystem: US Robotics/3Com USR 56k Internal FAX Modem (Model 2977)
>         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Interrupt: pin A routed to IRQ 5
>         Region 0: I/O ports at cc00 [size=8]
>         Capabilities: [dc] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> Any ideas?
>
> Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
William G. Unruh        Canadian Institute for          Tel: +1(604)822-3273
Physics&Astronomy          Advanced Research            Fax: +1(604)822-5324
UBC, Vancouver,BC        Program in Cosmology           unruh@physics.ubc.ca
Canada V6T 1Z1               and Gravity           www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
            http://www.theory.physics.ubc.ca/ppp-linux.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S318980AbSHWPWY>; Fri, 23 Aug 2002 11:22:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S318991AbSHWPWX>; Fri, 23 Aug 2002 11:22:23 -0400
Received: from windsormachine.com ([206.48.122.28]:29449 "EHLO
	router.windsormachine.com") by vger.kernel.org with ESMTP
	id <S318980AbSHWPWV>; Fri, 23 Aug 2002 11:22:21 -0400
Date: Fri, 23 Aug 2002 11:26:26 -0400 (EDT)
From: Mike Dresser <mdresser_l@windsormachine.com>
To: Bill Unruh <unruh@physics.ubc.ca>
cc: <linux-ppp@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33L2.0208230806050.16223-100000@string.physics.ubc.ca>
Message-ID: <Pine.LNX.4.33.0208231113550.8320-100000@router.windsormachine.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 23 Aug 2002, Bill Unruh wrote:

> Well, it would be good if you actually told us what problem you were
> describing. Is this a new connection attempt after the first hang up?
> What?
>
> What repeats over and over-- I see no repeat.

I >
> You also do not tell us info like what kind of modem is this-- external,
> internal, serial, usb, pci, winmodem,....
>
> I assume what you are refering to is the "inappropriate ioctl" line.
> This indicates a hardware problem.
>
> Actually, it looks to me like another pppd is up on the line. Those
> EchoReq are another pppd receiving stuff on an open pppd on another
> line. More information on what it is you are trying to do, on what your
> system is, and what the problem is might get you help.
>

Sorry.

It's a new connection from the persist option.  The exact same message
repeats for every dial out it attempts.

It's a PCI 3com 56k Sportster.  It's a hardware modem.

There is sometimes another pppd up on ttys1

Here's the setup:

There is an external modem on ttyS01, irq 3, that dials in occasionally as
needed.

there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
to the ISP.

Every 6 hours, the ISP enforces the 6 hour hangup rule they have.

The modem is set to persist, max-fails 0.  It is not able to redial, and
keeps giving the error message that i pasted.

Under 2.2.x, this functioned properly.

System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
Giga-byte, if I remember correctly.  Celeron 533.

Sorry about the too brief error message, I fell into my "it makes sense to
me the way it is" trap.

Mike


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S318907AbSHWQI0>; Fri, 23 Aug 2002 12:08:26 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S318888AbSHWQI0>; Fri, 23 Aug 2002 12:08:26 -0400
Received: from string.physics.ubc.ca ([142.103.234.11]:52905 "HELO
	string.physics.ubc.ca") by vger.kernel.org with SMTP
	id <S318876AbSHWQIX>; Fri, 23 Aug 2002 12:08:23 -0400
Date: Fri, 23 Aug 2002 09:12:34 -0700 (PDT)
From: Bill Unruh <unruh@physics.ubc.ca>
To: Mike Dresser <mdresser_l@windsormachine.com>
Cc: <linux-ppp@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33.0208231113550.8320-100000@router.windsormachine.com>
Message-ID: <Pine.LNX.4.33L2.0208230905440.16602-100000@string.physics.ubc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


OK, that problem is usually a "hardware" problem-- ie the hardware is
not responding properly to the icotl request. This could be because
there is not hardware there (eg trying to open a serial port which does
not exist on the machine), or is busy, or has been left in some weird
state. The last sounds most likely here-- eg the serial port on your
modem thinks it is still busy.

You could try running the little program I got basically from Carlson in
http://axion.physics.ubc.ca/modem-chk.html
to try resetting the serial line befor the next attempt (eg, put it into
/etc/ppp/ip-down).
Not sure if this is the problem however.

On Fri, 23 Aug 2002, Mike Dresser wrote:

> On Fri, 23 Aug 2002, Bill Unruh wrote:
>
> > Well, it would be good if you actually told us what problem you were
> > describing. Is this a new connection attempt after the first hang up?
> > What?
> >
> > What repeats over and over-- I see no repeat.
>
> I >
> > You also do not tell us info like what kind of modem is this-- external,
> > internal, serial, usb, pci, winmodem,....
> >
> > I assume what you are refering to is the "inappropriate ioctl" line.
> > This indicates a hardware problem.
> >
> > Actually, it looks to me like another pppd is up on the line. Those
> > EchoReq are another pppd receiving stuff on an open pppd on another
> > line. More information on what it is you are trying to do, on what your
> > system is, and what the problem is might get you help.
> >
>
> Sorry.
>
> It's a new connection from the persist option.  The exact same message
> repeats for every dial out it attempts.
>
> It's a PCI 3com 56k Sportster.  It's a hardware modem.
>
> There is sometimes another pppd up on ttys1
>
> Here's the setup:
>
> There is an external modem on ttyS01, irq 3, that dials in occasionally as
> needed.
>
> there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
> to the ISP.
>
> Every 6 hours, the ISP enforces the 6 hour hangup rule they have.
>
> The modem is set to persist, max-fails 0.  It is not able to redial, and
> keeps giving the error message that i pasted.
>
> Under 2.2.x, this functioned properly.
>
> System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
> Giga-byte, if I remember correctly.  Celeron 533.
>
> Sorry about the too brief error message, I fell into my "it makes sense to
> me the way it is" trap.
>
> Mike
>
>

-- 
William G. Unruh        Canadian Institute for          Tel: +1(604)822-3273
Physics&Astronomy          Advanced Research            Fax: +1(604)822-5324
UBC, Vancouver,BC        Program in Cosmology           unruh@physics.ubc.ca
Canada V6T 1Z1               and Gravity           www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
            http://www.theory.physics.ubc.ca/ppp-linux.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S319394AbSHWU3d>; Fri, 23 Aug 2002 16:29:33 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S319392AbSHWU3b>; Fri, 23 Aug 2002 16:29:31 -0400
Received: from windsormachine.com ([206.48.122.28]:42769 "EHLO
	router.windsormachine.com") by vger.kernel.org with ESMTP
	id <S319390AbSHWU32>; Fri, 23 Aug 2002 16:29:28 -0400
Date: Fri, 23 Aug 2002 16:33:29 -0400 (EDT)
From: Mike Dresser <mdresser_l@windsormachine.com>
To: Bill Unruh <unruh@physics.ubc.ca>
cc: <linux-ppp@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33L2.0208230905440.16602-100000@string.physics.ubc.ca>
Message-ID: <Pine.LNX.4.33.0208231619360.21045-100000@router.windsormachine.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 23 Aug 2002, Bill Unruh wrote:

>
> OK, that problem is usually a "hardware" problem-- ie the hardware is
> not responding properly to the icotl request. This could be because
> there is not hardware there (eg trying to open a serial port which does
> not exist on the machine), or is busy, or has been left in some weird
> state. The last sounds most likely here-- eg the serial port on your
> modem thinks it is still busy.
>
> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.

Another 7 minutes, and I'll know if this worked or not.

Another data point I just thought of, if i poff chatham, and then pon
chatham, that actually works.

It just hung up.

And redialed.

And connected properly.

Thank you so very much, it looks like your reset-serial did the job.

I'll implement it on future machines, just in case the same problem
happens, rather than pray it works.

I saw a lot of postings on the 5160 USR modem on the serial-pci-info list,
perhaps it's something to do with this modem.

I'll know for sure at 10:30 this evening, if it is definately owrking or
not.  I was logged in on the other line to monitor the syslog, and bring
up the internet line, just in case.

Thanks again,

Mike


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S316887AbSHYCBu>; Sat, 24 Aug 2002 22:01:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S316933AbSHYCBu>; Sat, 24 Aug 2002 22:01:50 -0400
Received: from windsormachine.com ([206.48.122.28]:63497 "EHLO
	router.windsormachine.com") by vger.kernel.org with ESMTP
	id <S316887AbSHYCBt>; Sat, 24 Aug 2002 22:01:49 -0400
Date: Sat, 24 Aug 2002 22:05:56 -0400 (EDT)
From: Mike Dresser <mdresser_l@windsormachine.com>
To: Bill Unruh <unruh@physics.ubc.ca>
cc: <linux-ppp@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.33L2.0208230905440.16602-100000@string.physics.ubc.ca>
Message-ID: <Pine.LNX.4.33.0208242204300.9317-100000@router.windsormachine.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 23 Aug 2002, Bill Unruh wrote:

> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.

It died again.

I'm going to go out there and swap out the modem with a different model if
i have one.  If that doesn't fix it, I'll get that VIA garbage out of the
system and replaced with a proper Intel 815 based motherboard.

Mike


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S314149AbSH0TXZ>; Tue, 27 Aug 2002 15:23:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S317072AbSH0TXZ>; Tue, 27 Aug 2002 15:23:25 -0400
Received: from willy.net1.nerim.net ([62.212.114.60]:38922 "EHLO
	www.home.local") by vger.kernel.org with ESMTP id <S314149AbSH0TXY>;
	Tue, 27 Aug 2002 15:23:24 -0400
Date: Tue, 27 Aug 2002 21:27:38 +0200
From: Willy Tarreau <willy@w.ods.org>
To: Steffen Persvold <sp@scali.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020827192738.GB28513@alpha.home.local>
References: <Pine.LNX.4.44.0208271934180.18659-100000@sp-laptop.isdn.scali.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0208271934180.18659-100000@sp-laptop.isdn.scali.no>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Aug 27, 2002 at 08:22:03PM +0200, Steffen Persvold wrote:
 
> I have an idea that this happens because the packets are comming out of 
> order into the receiving node (i.e the bonding device is alternating 
> between each interface when sending, and when the receiving node gets the 
> packets it is possible that the first interface get packets number 0, 2, 
> 4 and 6 in one interrupt and queues it to the network stack before packet 
> 1, 3, 5 is handled on the other interface).

You pointed your finger on this exact common problem.
You can use the XOR bonding mode (modprobe bonding mode=2), which uses a
hash of mac addresses to select the outgoing interface. This is interesting
if you have lots of L2 hosts on the same network switch.

Or if you have a few hosts on the same switch, you'd better use the "nexthop"
parameter of "ip route". IIRC, it should be something like :
  ip route add <destination> nexthop dev eth0 nexthop dev eth1
but read the help, I'm not certain.

Cheers,
Willy


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S319647AbSH3SvZ>; Fri, 30 Aug 2002 14:51:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S319649AbSH3SvY>; Fri, 30 Aug 2002 14:51:24 -0400
Received: from ziggy.one-eyed-alien.net ([64.169.228.100]:27398 "EHLO
	ziggy.one-eyed-alien.net") by vger.kernel.org with ESMTP
	id <S319647AbSH3SvX>; Fri, 30 Aug 2002 14:51:23 -0400
Date: Fri, 30 Aug 2002 11:55:47 -0700
From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020830115546.E5131@one-eyed-alien.net>
Mail-Followup-To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>,
	linux-kernel@vger.kernel.org
References: <180577A42806D61189D30008C7E632E8793A25@boca213a.boca.ssc.siemens.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="cPi+lWm09sJ+d57q"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <180577A42806D61189D30008C7E632E8793A25@boca213a.boca.ssc.siemens.com>; from Jack.Bloch@icn.siemens.com on Fri, Aug 30, 2002 at 02:43:52PM -0400
Organization: One Eyed Alien Networks
X-Copyright: (C) 2002 Matthew Dharm, all rights reserved.
X-Message-Flag: Get a real e-mail client.  http://www.mutt.org/
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--cPi+lWm09sJ+d57q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I would simply recommend switching to ext3, where these types of errors
generally don't occur.

Oh, and if you just edit your initscripts, you can do anything you want.

Matt

On Fri, Aug 30, 2002 at 02:43:52PM -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipp=
ed
> with keyboard and monitor). Is there any way to invoke e2fsck automatical=
ly
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
>=20
>=20
> Thanks in advance....
>=20
> Jack Bloch=20
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
>=20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--=20
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=
net=20
Maintainer, Linux USB Mass Storage Driver

My mother not mind to die for stoppink Windows NT!  She is rememberink=20
Stalin!
					-- Pitr
User Friendly, 9/6/1998

--cPi+lWm09sJ+d57q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9b7+yIjReC7bSPZARAtQpAKCsm3v0QvbI3Pg9zKY670apTF4wkACdGdnW
dhSgmPcmvrt+6DWLay0qMVI=
=/yx6
-----END PGP SIGNATURE-----

--cPi+lWm09sJ+d57q--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S319653AbSH3TVC>; Fri, 30 Aug 2002 15:21:02 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S319654AbSH3TVC>; Fri, 30 Aug 2002 15:21:02 -0400
Received: from h24-67-14-151.cg.shawcable.net ([24.67.14.151]:2813 "EHLO
	webber.adilger.int") by vger.kernel.org with ESMTP
	id <S319653AbSH3TVB>; Fri, 30 Aug 2002 15:21:01 -0400
From: Andreas Dilger <adilger@clusterfs.com>
Date: Fri, 30 Aug 2002 13:22:54 -0600
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20020830192254.GA32468@clusterfs.com>
Mail-Followup-To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>,
	linux-kernel@vger.kernel.org
References: <180577A42806D61189D30008C7E632E8793A25@boca213a.boca.ssc.siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <180577A42806D61189D30008C7E632E8793A25@boca213a.boca.ssc.siemens.com>
User-Agent: Mutt/1.4i
X-GPG-Key: 1024D/0D35BED6
X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F  8A29 A488 39F5 0D35 BED6
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Aug 30, 2002  14:43 -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.

I would instead suggest using a filesystem like JFFS2 for flash devices.
This is journaled like ext3, but it also has the benefit of doing wear
levelling on the device, which otherwise will probably wear out the
superblock part of the flash rather quickly.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S313190AbSHaAJY>; Fri, 30 Aug 2002 20:09:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S314602AbSHaAJX>; Fri, 30 Aug 2002 20:09:23 -0400
Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:22770 "EHLO
	passion.cambridge.redhat.com") by vger.kernel.org with ESMTP
	id <S313190AbSHaAJX>; Fri, 30 Aug 2002 20:09:23 -0400
X-Mailer: exmh version 2.5 13/07/2001 with nmh-1.0.4
From: David Woodhouse <dwmw2@infradead.org>
X-Accept-Language: en_GB
In-Reply-To: <20020830192254.GA32468@clusterfs.com> 
References: <20020830192254.GA32468@clusterfs.com>  <180577A42806D61189D30008C7E632E8793A25@boca213a.boca.ssc.siemens.com> 
To: Andreas Dilger <adilger@clusterfs.com>
Cc: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>, linux-kernel@vger.kernel.org
Subject: Re: your mail 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Sat, 31 Aug 2002 01:12:56 +0100
Message-ID: <16211.1030752776@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



adilger@clusterfs.com said:
>  I would instead suggest using a filesystem like JFFS2 for flash
> devices. This is journaled like ext3, but it also has the benefit of
> doing wear levelling on the device, which otherwise will probably wear
> out the superblock part of the flash rather quickly. 

He said he's using CompactFlash. CompactFlash is not flash, as far as we're
concerned: it is an IDE drive. You may think it has flash inside it; we
couldn't possibly comment.

In fact, it generally has a kind of pseudo-filesystem internally which it 
uses to emulate a block device with 512-byte sectors. It may do its own 
wear-levelling; the manufacturers are often quite cagey about whether it 
actually does or not. Draw your own conclusions about that if you will.

It's quite common to find that this internal pseudo-filesystem _itself_ gets
screwed on power failures. This tends to manifest itself as unrecoverable 
I/O errors.

There is no fundamental reason why every CF card should have these 
problems, in the same way as there is no fundamental reason why all PC 
BIOSes should be crap. But the same expectations apply.

If you want to pass power-fail testing, I would recommend you switch to
using real flash. JFFS2 on real flash has survived days of stress testing
whilst being power cycled randomly every ~5 minutes. The same tests were 
observed to destroy CF cardsš.

CF is bog-roll technology. It's disposable storage designed for temporary
use in stuff like cameras -- not for real computing. Think of it like a
floppy disc and you won't go far wrong.

--
dwmw2
š http://www.embeddedlinuxworks.com/articles/jffs_guide.html˛
˛ Constant reboots no longer screw the wear levelling, as reported there.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S316601AbSIAJyL>; Sun, 1 Sep 2002 05:54:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S316608AbSIAJyL>; Sun, 1 Sep 2002 05:54:11 -0400
Received: from pd192.swietochlowice.sdi.tpnet.pl ([80.49.41.192]:18180 "EHLO
	cyborg.kernel.pl") by vger.kernel.org with ESMTP id <S316601AbSIAJyK>;
	Sun, 1 Sep 2002 05:54:10 -0400
Date: Sun, 1 Sep 2002 11:53:07 +0200 (CEST)
From: Krzysiek Taraszka <dzimi@pld.org.pl>
X-X-Sender: dzimi@chropaczow.eu.org
To: linuxppc-dev@lists.linuxppc.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <200208312335.g7VNZmk37659@sullivan.realtime.net>
Message-ID: <Pine.LNX.4.44L.0209011134310.2567-100000@chropaczow.eu.org>
References: <200208312335.g7VNZmk37659@sullivan.realtime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 31 Aug 2002, Milton Miller wrote:

> At Fri Aug 30 2002 - 12:54:37 EST Krzysiek Taraszka (dzimi@pld.org.pl) wrote:
> > Great work, but in 2.2.22rc2 powerpc's still broken.
> > First of All Sources have got a lot of unsed stuff.
> > For example look like that:
> > 
> > [dzimi@cyborg linux]$ rgrep -n -R '*.*' 'CONFIG_PPC64' . 
> ...
> 
> Doesn't sound like -rc (release canidate) changes.

Well yes, in 2.2.10 someone tried to add CONFIG_PPC64 support in to 2.2 
kernel.
In 2.2.11 someone add CONFIG_PPC64 in to Config.in! but on 2.2.12 or 
2.2.13 someone remove it ... 
(without remove it from directory != arch/ppc/kernel/ )
 
> > Second kernel-2.2.21 still have got time init problems in symbios driver
> > on powerpc platform.
> > I send to you my ugly hack witch work, but IMHO he's ugly ;) I need to do
> > it correct.
> 
> > Third, kernel for powerpc boot and work on g3-266 but on g3-333 Ops ...
> > (kernel traps, kernel wrote: Caused by SRR1 or somethink like that, in 2.3
> > i saw #define FIX_SRR1 macro ...)
> 
> Well, SRR1 doesn't cause traps, but it does help tell you why they occurred.
> And the FIX_SRR1 stuff isn't the solution either if you look at it closer.
> How about a decoded oops?  Also, you didn't say what platform you were using.

I used g3 (pmac). My based system was PLD with 2.4.18 tree.
I used gcc-2.95.4 to build 2.2.21 vmlinux.

> As far as the open-pic changes you posted, how about explaining what your
> trying to fix (partly hidden by the rename and move to chrp_setup.c from
> open_pic.c)?

I tried to fix problem witch is on my IBM RS/6000 (model b50).
Openpic can't initialize propertly my scsi system. (sym82c8xx scsi 
driver). Some time init problems.

Oh I forgot, 2.2.22rc1/2 or kernel >= 2.2.16 (2.2 tree) didn't work on my 
IBM RS/6000 (b50).
Build with egcs work, but work slow (Bogomips: 16MHz!) and won't reboot 
and shutdown -h now.
The same code build with gcc Ops (Kernel Exception, look like openpic 
allocation address.)
I'll post the Ops later.

> I see you are wrapping the 8259 checks, but it also refers to a few new
> functions/macros I didn't see defined.

Hmm, yes, that why my patch is ugly. I want to do this correctly.
 
> How about discussing these problems and patches over at
> linuxppc-dev@lists.linuxppc.org ? (I set the reply-to there).

Ok, but first of all i should subscribe there.

Krzysiek Taraszka			(dzimi@pld.org.pl)



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S317385AbSINRBR>; Sat, 14 Sep 2002 13:01:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S317392AbSINRBR>; Sat, 14 Sep 2002 13:01:17 -0400
Received: from 2-028.ctame701-1.telepar.net.br ([200.193.160.28]:62085 "EHLO
	2-028.ctame701-1.telepar.net.br") by vger.kernel.org with ESMTP
	id <S317385AbSINRBQ>; Sat, 14 Sep 2002 13:01:16 -0400
Date: Sat, 14 Sep 2002 14:05:49 -0300 (BRT)
From: Rik van Riel <riel@conectiva.com.br>
X-X-Sender: riel@imladris.surriel.com
To: Paolo Ciarrocchi <ciarrocchi@linuxmail.org>
cc: linux-kernel@vger.kernel.org, <conman@kolivas.net>
Subject: Re: your mail
In-Reply-To: <20020914123948.26265.qmail@linuxmail.org>
Message-ID: <Pine.LNX.4.44L.0209141405160.1857-100000@imladris.surriel.com>
X-spambait: aardvark@kernelnewbies.org
X-spammeplease: aardvark@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 14 Sep 2002, Paolo Ciarrocchi wrote:

> I think that only the _memload_ test is not
> working with 2.5.*, am I wrong?

You're right, the memload test doesn't work with 2.5 but
needs the following patch...

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org


--- contest-0.1/mem_load.c.orig	2002-09-13 23:36:47.000000000 -0400
+++ contest-0.1/mem_load.c	2002-09-14 11:10:07.000000000 -0400
@@ -47,24 +47,25 @@
   switch (type) {

   case 0: /* RAM */
-    if ((position = strstr(buffer, "Mem:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Mem:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "MemTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"MemTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Mem:  %ul", &size);
+    sscanf (position, "MemTotal:  %ul", &size);
     break;

   case 1:
-    if ((position = strstr(buffer, "Swap:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Swap:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "SwapTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"SwapTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Swap: %ul", &size);
+    sscanf (position, "SwapTotal: %ul", &size);
     break;

   }

-  return (size / MB);
+  /* convert from kB to MB */
+  return (size / KB);

 }

--- contest-0.1/mem_load.h.orig	2002-09-14 11:09:28.000000000 -0400
+++ contest-0.1/mem_load.h	2002-09-14 11:09:42.000000000 -0400
@@ -24,6 +24,7 @@

 #define MAX_BUF_SIZE 1024          /* size of /proc/meminfo in bytes */
 #define MB (1024 * 1024)           /* 2^20 bytes */
+#define KB 1024
 #define MAX_MEM_IN_MB (1024 * 64)  /* 64 GB */

 /* Tuning parameter.  Increase if you are getting an 'unreasonable' load


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261386AbSIWS32>; Mon, 23 Sep 2002 14:29:28 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261389AbSIWS32>; Mon, 23 Sep 2002 14:29:28 -0400
Received: from air-2.osdl.org ([65.172.181.6]:47757 "EHLO cherise.pdx.osdl.net")
	by vger.kernel.org with ESMTP id <S261386AbSIWS27>;
	Mon, 23 Sep 2002 14:28:59 -0400
Date: Mon, 23 Sep 2002 11:35:55 -0700 (PDT)
From: Patrick Mochel <mochel@osdl.org>
X-X-Sender: mochel@cherise.pdx.osdl.net
To: "Rhoads, Rob" <rob.rhoads@intel.com>
cc: Greg KH <greg@kroah.com>, <linux-kernel@vger.kernel.org>,
       <hardeneddrivers-discuss@lists.sourceforge.net>,
       <cgl_discussion@lists.osdl.org>
Subject: Re: your mail
In-Reply-To: <20020921053214.GA26254@kroah.com>
Message-ID: <Pine.LNX.4.44.0209231000110.6409-100000@cherise.pdx.osdl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


In general, I agree completely with what Greg says (as usual), but I do 
have a few additional comments.

> (I'll skip the intro, and feel good sections and get into the details
> that you lay out, starting in section 2)
> 
> Section 2:
> 2.1:
> 	- do NOT use /proc for driver info.  Use driverfs.
> 	- If you are using a kernel version that does not have driverfs,
> 	  put all /proc driver info under /proc/drivers, which is where
> 	  it belongs.

Actually, they mention using driverfs in Section 3: Instrumentation. I 
can't tell if this was around before, or this was just added. The date is 
the same (16 Aug), but there is no changelog information about the spec. 

I would suggest not using procfs at all, even if driverfs is not avaiable.  
If you're using 2.4, backport driverfs, or clone it for your own
filesystem. It's not dependent on the driver model at all, and has been
done at least once before (Greg's pcihpfs).

> Section 3:

> The Common Statistic Manager:

Please drop the term 'Manager' from your nomenclature. It is ambiguous, 
because of the context in which its generally used in. Windows uses the 
term for any collection of kernel or device data and/or kernel policy. 
It's not a bad term, but it fails to make a clear distinction between 
kernel space and user space, which we insist on. 

Only the mechanism for setting the policy should exist in the kernel, and
itself my be very intelligent. But, the policy itself should exist outside
of the kernel.


> 3.2.5.2:
> (I'm not condoning ANY of these functions or code, just trying to point out how
> you should, if they were to be in the kernel, done properly.)
> 	- do not use typedef
> 	- struct stat_info does not need *unit, as that is already
> 	  specified in the scale field, right?
> 	- the stat_value_t union is just a horrible abomination, don't
> 	  do that.

Please do not pass void *. You should only pass type-safe structures. If 
you cannot get that information, you should redesign the API. 

> 3.4 Event logging:
> 	- I'm not even going to touch this, sorry.

There are a lot of topics in this spec, most of which are irrelevant to 
actually hardening drivers. They may be features dependent on your APIs, 
but they are completely optional and may hinder acceptance of your primary 
objectives. 

Event logging is definitely one of them, esp. with a function like

evl_log_event_string(  
	ME_EVENT_BUCKET_EMPTY, 
	LOG_WARNING, 
	"Leaky bucket exception (bucket empty):\ 
	Bucket_Level <= Observed_Value - Last_Value\ 
	|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s\ 
	|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|", 
	RMGT_FacilityIDAttrStr,         RMUUID, 
	RMGT_SubsystemIDAttrStr,    SUBSYSTEM_UUID, 
	RMGT_SubsystemNameAttrStr,  subsystem_name, 
	RMGT_ResourceIDAttrStr,         resource_id, 
	RMGT_ResourceNameAttrStr,   resource_name, 
	ME_MonitorIDAttrStr,        monitor_uuid,  
	ME_StatisticIDAttrStr,         statistic_id, 
	ME_StatisticNameAttrStr,    statistic_name,  
	ME_BucketSizeAttrStr,       bucketsz,  
	ME_FillValueAttrStr,            fillval, 
	ME_FillIntervalAttrStr,         fillint, 
	ME_BucketLevelAttrStr,      bucketlvl, 
	ME_ObservedValueAttrStr,    obsval, 
	ME_LastValueAttrStr,        lastval); 


> In summary, I think that a lot of people have spent a lot of time in
> creating this document, and the surrounding code that matches this
> document.  I really wish that a tiny bit of that effort had gone into
> contacting the Linux kernel development community, and asking to work
> with them on a project like this.  Due to that not happening, and by
> looking at the resultant spec and code, I'm really afraid the majority
> of that time and effort will have been wasted.

I completely agree. There is definitely good intention in some aspects of 
the spec, and definitely in the effort put forth to support this type of 
work. But, in order to gain the support of kernel developers, or even the 
blessing of a few, you should be working with them on the design from the 
beginnging.

Designing APIs is hard. Doing it well is very hard. I'm not claiming I've 
done a stellar job, but I have at least learned that. I've made a lot of 
poor design decisions, many of which are also evident in your code 
descriptions and examples. I can't tell you how many times I've rewritten 
things over and over and over because someone hated them (usually Linus or 
Greg).

There are people that are willing to help, as we are trying to do. But,
it's much easier if you do things gradually and get that help from the
beginning.

> What do I think can be salvaged?  Diagnostics are a good idea, and I
> think they fit into the driver model in 2.5 pretty well.  A lot of
> kernel janitoring work could be done by the CG team to clean up, and
> harden (by applying the things in section 2) the existing kernel
> drivers.  That effort alone would go a long way in helping the stability
> of Linux, and also introduce the CG developers into the kernel community
> as active, helping developers.  It would allow the CG developers to
> learn from the existing developers, as we must be doing something right
> for Linux to be working as well as it does :)

Which kernel are you targeting? I didn't see it in the spec, though I 
could have easily missed it. CGL is based on 2.4, so I would assume that. 
But, I would think the ideal choice would be to start in 2.5 and backport 
it to 2.4. 

If that's the case, how do you intend to work with the driver model? 
There will be quite a bit of code and interface duplication between
your code and the driver model. I can see ways to support many of the
things you want in a relatively easy manner, and not punish the common
user or developer; but the margin is to small to write the answer... ;)

Also, there are many projects in areas similar to what your doing: 
diganostics, HA, etc, etc. It would be nice to see some collaboration 
between the developers of those projects instead of having many disparate 
projects with similar goals. 


	-pat







From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S263084AbSJBMqL>; Wed, 2 Oct 2002 08:46:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S263085AbSJBMqK>; Wed, 2 Oct 2002 08:46:10 -0400
Received: from pasmtp.tele.dk ([193.162.159.95]:3079 "EHLO pasmtp.tele.dk")
	by vger.kernel.org with ESMTP id <S263084AbSJBMqJ>;
	Wed, 2 Oct 2002 08:46:09 -0400
Date: Wed, 2 Oct 2002 14:51:10 +0200
From: Sam Ravnborg <sam@ravnborg.org>
To: s.stoklossa@mentopolis.de
Cc: mec@shout.net, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20021002145110.D1369@mars.ravnborg.org>
Mail-Followup-To: s.stoklossa@mentopolis.de, mec@shout.net,
	linux-kernel@vger.kernel.org
References: <OF306CCF12.3BC6EB60-ONC1256C46.00458246@mentopolis.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <OF306CCF12.3BC6EB60-ONC1256C46.00458246@mentopolis.de>; from s.stoklossa@mentopolis.de on Wed, Oct 02, 2002 at 02:41:42PM +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Oct 02, 2002 at 02:41:42PM +0200, s.stoklossa@mentopolis.de wrote:
> beim versuch, die Einstellungen von alsa aufzurufen, kam folgende FM:
> 
>  Q> ./scripts/Menuconfig: MCmenu74: command not found
> 
> grusz
> 
> Sven
Known problem, try this patch:
copy-n-pated so may not apply cleanly, try by hand.
Ps. Please in english next time.

        Sam

--- linux/sound/Config.in       2002-10-01 12:09:44.000000000 +0200
+++ linux/sound/Config.in       2002-10-01 12:21:05.000000000 +0200
@@ -31,10 +31,7 @@
 if [ "$CONFIG_SND" != "n" -a "$CONFIG_ARM" = "y" ]; then
   source sound/arm/Config.in
 fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ]; then
-  source sound/sparc/Config.in
-fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC64" = "y" ]; then
+if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ] || [ "$CONFIG_SND" !=
"n" -a "$CONFIG_SPARC64" = "y" ] ; then
   source sound/sparc/Config.in
 fi

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262589AbSJBUGR>; Wed, 2 Oct 2002 16:06:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262590AbSJBUGR>; Wed, 2 Oct 2002 16:06:17 -0400
Received: from 62-190-217-232.pdu.pipex.net ([62.190.217.232]:38156 "EHLO
	darkstar.example.net") by vger.kernel.org with ESMTP
	id <S262589AbSJBUGP>; Wed, 2 Oct 2002 16:06:15 -0400
From: jbradford@dial.pipex.com
Message-Id: <200210022019.g92KJSNr001989@darkstar.example.net>
Subject: Re: your mail
To: peloquin@us.ibm.com (Mark Peloquin)
Date: Wed, 2 Oct 2002 21:19:28 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
In-Reply-To: <OF527144DA.FA032B8F-ON85256C46.0065456B@pok.ibm.com> from "Mark Peloquin" at Oct 02, 2002 02:58:25 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> On Wed, 2002-10-02 at 17:09, Alan Cox wrote:
> > Look at history - if such a mess got in, it would never get sorted.
> 
> Instead of throwing around vague statements with little
> context like "compost heap" and "such a mess", why don't
> you spell out the specific design points of EVMS that you
> disagree with. The advantages and disadvantages of
> each point can then be discussed.

Yeah, but he is right in any case - look how the IDE mess of 2.5.x, which, frankly, I don't believe was ever as bad as people seem to be saying it was, has put people off testing 2.5.x.  Instead they are waiting for Linus to type

mv linux-2.5.x linux-2.6.0

at which point they think that all remaining bugs will auto-magically correct themselves and the tree is one again safe to use.  WRONG answer!

Simply from the point of view of not wanting to 'scare off' people from a whole tree, (which is so rediculous, I think I'll go and patent it), and as a result get less testing, we're better off trying to stop weirdness from getting in.

John.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261605AbSJNMT7>; Mon, 14 Oct 2002 08:19:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261609AbSJNMT7>; Mon, 14 Oct 2002 08:19:59 -0400
Received: from noodles.codemonkey.org.uk ([213.152.47.19]:46817 "EHLO
	noodles.internal") by vger.kernel.org with ESMTP id <S261605AbSJNMT6>;
	Mon, 14 Oct 2002 08:19:58 -0400
Date: Mon, 14 Oct 2002 13:28:24 +0100
From: Dave Jones <davej@codemonkey.org.uk>
To: Maros RAJNOCH /HiaeR Silvanna/ <rajnoch@sophia.dtp.fmph.uniba.sk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20021014122824.GB29240@suse.de>
Mail-Followup-To: Dave Jones <davej@codemonkey.org.uk>,
	Maros RAJNOCH /HiaeR Silvanna/ <rajnoch@sophia.dtp.fmph.uniba.sk>,
	linux-kernel@vger.kernel.org
References: <20021014082828.B31820@sophia.dtp.fmph.uniba.sk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021014082828.B31820@sophia.dtp.fmph.uniba.sk>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Oct 14, 2002 at 08:28:28AM +0200, Maros RAJNOCH /HiaeR Silvanna/ wrote:
 > Linux version 2.4.2-2 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001

1, 2.4.2 is /very/ old, there are updated errata kernel packages at
    ftp.redhat.com
2, Bugs in Red Hat's kernel should be filed in http://bugzilla.redhat.com
   and not in linux-kernel.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261498AbSJQOub>; Thu, 17 Oct 2002 10:50:31 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261502AbSJQOua>; Thu, 17 Oct 2002 10:50:30 -0400
Received: from chaos.physics.uiowa.edu ([128.255.34.189]:28070 "EHLO
	chaos.physics.uiowa.edu") by vger.kernel.org with ESMTP
	id <S261498AbSJQOu3>; Thu, 17 Oct 2002 10:50:29 -0400
Date: Thu, 17 Oct 2002 09:56:08 -0500 (CDT)
From: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
X-X-Sender: kai@chaos.physics.uiowa.edu
To: Rusty Russell <rusty@rustcorp.com.au>
cc: Daniel Phillips <phillips@arcor.de>, <S@samba.org>,
       Roman Zippel <zippel@linux-m68k.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20021017075539.8DE762C0CA@lists.samba.org>
Message-ID: <Pine.LNX.4.44.0210170930410.6301-100000@chaos.physics.uiowa.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 17 Oct 2002, Rusty Russell wrote:

> > But that one is easy: the zero check just takes the same spinlock as 
> > TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
> > is zero, considerably simpler than:
> 
> The current spinlock is horrible.  You could use a brlock, of course,
> but I didn't mainly because of code bloat and speed.  My current code
> looks like:
> 
> static inline int try_module_get(struct module *module)
> {
> 	int ret = 1;
> 
> 	if (module) {
> 		unsigned int cpu = get_cpu();
> 		if (likely(module->ref[cpu].live))
> 			local_inc(&module->ref[cpu].counter);
> 		else
> 			ret = 0;
> 		put_cpu();
> 	}
> 	return ret;
> }

Since I made the mistake of getting involved into this discussion lately,
I wonder if this new method is going to be mandatory (the only one
available) or optional. I think there's two different kind of users, for
one modules which use an API which provides its own infrastructure for
dealing with modules via ->owner, on the other hand things like netfilter
(that's probably where you are coming from) where calls into a module,
which need protection are really frequent.

Note that for the vast majority of modules, dealing with unload races is 
as simple as setting ->owner, for example filesystems, network drivers.

Sure, we need a global lock (unload_lock) when calling into these modules
initially, but these "binding/unbinding" calls are really rare. For
filesystems, they happen once per mount, for network drivers only for
ifconfig up/down. Afterwards, calling into the module (e.g. accessing the
mounted filesystem, xmitting/receiving data) doesn't have any overhead at
all compared to a linked-in filesystem/driver (well, ignore TLB misses)

I don't see a good reason to change this, in particular, since it provides 
useful information to the user, that is the mod_use_count. It means "Is it 
possible to successfully unload the module now?", and since looking at
the count and the actual unload is protected by unload_lock, the unload 
will either succeed basically immediately, or fail with -EBUSY right away.

I see that your approach makes frequent calls into the module cheaper, but
I'm not totally convinced that the current safe interfaces need to change
just to accomodate rare cases like netfilter (there's most likely some
more cases like it, but the majority of modules is not).

Anyway, I may see further problems, but let me check first: Is your count
supposed to only count users which are currently executing in the module's
.text, or is it also to count references to data allocated in the module?
(I.e. when I register_netdev(), does that keep a reference to the module
even after the code has left the module's .text?)

--Kai


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262814AbSJRCug>; Thu, 17 Oct 2002 22:50:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262815AbSJRCug>; Thu, 17 Oct 2002 22:50:36 -0400
Received: from dp.samba.org ([66.70.73.150]:42118 "EHLO lists.samba.org")
	by vger.kernel.org with ESMTP id <S262814AbSJRCuc>;
	Thu, 17 Oct 2002 22:50:32 -0400
From: Rusty Russell <rusty@rustcorp.com.au>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: Daniel Phillips <phillips@arcor.de>, S@samba.org,
       Roman Zippel <zippel@linux-m68k.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-reply-to: Your message of "Thu, 17 Oct 2002 09:56:08 EST."
             <Pine.LNX.4.44.0210170930410.6301-100000@chaos.physics.uiowa.edu> 
Date: Fri, 18 Oct 2002 12:47:56 +1000
Message-Id: <20021018025633.1D4C72C0BF@lists.samba.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

In message <Pine.LNX.4.44.0210170930410.6301-100000@chaos.physics.uiowa.edu> yo
u write:
> Since I made the mistake of getting involved into this discussion lately,

My condolences. 8)

> I wonder if this new method is going to be mandatory (the only one
> available) or optional. I think there's two different kind of users, for
> one modules which use an API which provides its own infrastructure for
> dealing with modules via ->owner, on the other hand things like netfilter
> (that's probably where you are coming from) where calls into a module,
> which need protection are really frequent.

Mandatory for interfaces where the function can sleep (or be preempted).

> Note that for the vast majority of modules, dealing with unload races is 
> as simple as setting ->owner, for example filesystems, network drivers.

Yes.  We do not have complete coverage though, this policy would
extend it.

> I see that your approach makes frequent calls into the module cheaper, but
> I'm not totally convinced that the current safe interfaces need to change
> just to accomodate rare cases like netfilter (there's most likely some
> more cases like it, but the majority of modules is not).

They're not changing.  The current users doing try_inc_mod_count() are
fine.  It's the ones not doing it which are problematic.

> Anyway, I may see further problems, but let me check first: Is your count
> supposed to only count users which are currently executing in the module's
> .text, or is it also to count references to data allocated in the module?
> (I.e. when I register_netdev(), does that keep a reference to the module
> even after the code has left the module's .text?)

It's to protect entry to the function, but of course, some interfaces
(eg. filesystems) lend themselves very neatly to batching this at
mount/unmount time.  Data is already protected by the usual means.

At risk of boring you, here's the document from the documentation
patch.  Suggestions welcome.

+Writing Modules and the Interfaces To Be Used By Them: A Gentle Guide.
+Copyright 2002, Rusty Russell IBM Corportation
+
+Modules are running parts of the kernel which can be added, and
+sometimes removed, while the kernel is operational.
+
+There are several delicate issues involved in this procedure which
+indicate special care should be taken.
+
+There are three cases you need to be careful:
+
+1) Any code which creates an interface for callbacks (ie. almost any
+   function called register_*)
+	=> See Rule #1
+
+2) Any modules which use (old) interfaces which do not obey Rule #1
+	=> See Rule #2
+
+Rule #1: Module-safe Interfaces.  Any interface which allows
+	registration of callbacks, must also allow registration of a
+	"struct module *owner", either in the structure or as a
+	function parameter, and it must use them to protect the
+	callbacks.  See "MAKING INTERFACES SAFE".
+
+Exception #1: As an optimization, you may skip this protection if you
+	   *know* that the callbacks are non-preemtible and never
+	   sleep (eg. registration of interrupt handlers).
+
+
+Rule #2: Modules using unsafe interfaces.  If your module is using any
+	interface which does not obey rule number 1, that means your
+	module functions may be called from the rest of the kernel
+	without the caller first doing a successful try_module_get().
+
+	You must not register a "module_cleanup" handler, and your module
+	cannot be unloaded except by force.  You must be especially
+	careful in this case with initialization: see "INITIALIZING
+	MODULES WHICH USE UNSAFE INTERFACES".
+
+MAKING INTERFACES SAFE
+
+A caller must always call "try_module_get()" on a function pointers's
+owner before calling through that function pointer.  If
+"try_module_get()" returns 0 (false), the function pointer must *not*
+be called, and the caller should pretend that registration does not
+exist: this means the (module) owner is closing down and doesn't want
+any more calls, or in the process of starting up and isn't ready yet.
+
+For many interfaces, this can be optimized by assuming that a
+structure containing function pointers has the same owner, and knowing
+that one function is always called before the others, such as the
+filesystem code which knows a mount must succeed before any other
+methods can be accessed.
+
+You must call "module_put()" on the owner sometime after you have
+called the function(s).
+
+If you cannot make your interface module-safe in this way, you can at
+least split registration into a "reserve" stage and an "activate"
+stage, so that modules can use the interface, even if they cannot
+(easily) unload.
+
+
+INITIALIZING MODULES WHICH USE UNSAFE INTERFACES
+
+Safe interfaces will never enter your module before module_init() has
+successfully finished, but unsafe interfaces may.  The rule is simple:
+your init_module() function *must* succeed (by returning 0) if it has
+successfully used any unsafe interfaces.
+
+So, if you are only using ONE unsafe interface, simply use that
+interface last.  Otherwise you will have to use printk() to report
+failure and leave the module initialized (but possibly useless).
+
+
+
+If you have questions about how to apply this document to your own
+modules, please ask rusty@rustcorp.com.au or linux-kernel@vger.kernel.org.
+
+Thankyou,
+Rusty.

--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265394AbSJRVo1>; Fri, 18 Oct 2002 17:44:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265412AbSJRVo1>; Fri, 18 Oct 2002 17:44:27 -0400
Received: from chaos.physics.uiowa.edu ([128.255.34.189]:11947 "EHLO
	chaos.physics.uiowa.edu") by vger.kernel.org with ESMTP
	id <S265394AbSJRVo0>; Fri, 18 Oct 2002 17:44:26 -0400
Date: Fri, 18 Oct 2002 16:50:17 -0500 (CDT)
From: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
X-X-Sender: kai@chaos.physics.uiowa.edu
To: Rusty Russell <rusty@rustcorp.com.au>
cc: Daniel Phillips <phillips@arcor.de>, <S@samba.org>,
       Roman Zippel <zippel@linux-m68k.org>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail 
In-Reply-To: <20021018025633.1D4C72C0BF@lists.samba.org>
Message-ID: <Pine.LNX.4.44.0210181647410.10010-100000@chaos.physics.uiowa.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 18 Oct 2002, Rusty Russell wrote:

> > I wonder if this new method is going to be mandatory (the only one
> > available) or optional. I think there's two different kind of users, for
> > one modules which use an API which provides its own infrastructure for
> > dealing with modules via ->owner, on the other hand things like netfilter
> > (that's probably where you are coming from) where calls into a module,
> > which need protection are really frequent.
> 
> Mandatory for interfaces where the function can sleep (or be preempted).

and is not protected by other means (try_inc_mod_count()), I presume.

> > I see that your approach makes frequent calls into the module cheaper, but
> > I'm not totally convinced that the current safe interfaces need to change
> > just to accomodate rare cases like netfilter (there's most likely some
> > more cases like it, but the majority of modules is not).
> 
> They're not changing.  The current users doing try_inc_mod_count() are
> fine.  It's the ones not doing it which are problematic.

Alright, so I'm fine with it ;) (not that makes a difference, but...)

--Kai



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S264669AbSJ3N4o>; Wed, 30 Oct 2002 08:56:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S264673AbSJ3N4o>; Wed, 30 Oct 2002 08:56:44 -0500
Received: from chaos.analogic.com ([204.178.40.224]:65408 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id <S264669AbSJ3N4n>; Wed, 30 Oct 2002 08:56:43 -0500
Date: Wed, 30 Oct 2002 09:04:51 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Roberto Fichera <kernel@tekno-soft.it>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <5.1.1.6.0.20021030132848.03a12ec0@mail.isolaweb.it>
Message-ID: <Pine.LNX.3.95.1021030090019.5487A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 30 Oct 2002, Roberto Fichera wrote:

> I've a problem with a DAT on a Compaq Proliant ML350 with PIII 1GHz,
> 1Gb RAM, RAID controller Smart Array 451 with 3 x HDD 9Gb RAID 5
> and an internal SCSI controller Adaptec 7899 Ultra160 where is connected
> only a DAT 12/24 Gb. Current installed distribution is RH7.3 with its kernel
> 2.4.18-10 but I've tryed the standard 2.4.19 with the same problem.
> The problem is that the DAT don't work any more with Linux. This DAT work
> well on Win2K :-(! Below  there is some logs and a 'ps fax' showing a tar in
> D state.
> 
> Does anyone know a solution ?

> 
> Adaptec AIC7xxx driver version: 6.2.6
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> Corrupted Serial EEPROM
^^^^^^^^^^^^^^^^^^^^^^^^^

I think your controller has fallen-back into survival mode
because it lost it's mind. You may want to upgrade the
controller BIOS to fix this problem. Then, see if it handles
tapes okay.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265266AbSJaRzx>; Thu, 31 Oct 2002 12:55:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265261AbSJaRzx>; Thu, 31 Oct 2002 12:55:53 -0500
Received: from bgp01387421bgs.brodwy01.nm.comcast.net ([68.35.130.254]:41600
	"EHLO www.tojabr.com") by vger.kernel.org with ESMTP
	id <S265266AbSJaRxv>; Thu, 31 Oct 2002 12:53:51 -0500
Date: Thu, 31 Oct 2002 11:00:16 -0700 (MST)
From: Tom Bradley <tojabr@tojabr.com>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <180577A42806D61189D30008C7E632E8793B26@boca213a.boca.ssc.siemens.com>
Message-ID: <Pine.LNX.4.44.0210311059250.3676-100000@www.tojabr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

They are just regular values. The UL tells the compiler to format the
number as an unsgned long.


On Thu, 31 Oct 2002, Bloch, Jack wrote:

> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL.  I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262879AbSJaSIf>; Thu, 31 Oct 2002 13:08:35 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262838AbSJaSH1>; Thu, 31 Oct 2002 13:07:27 -0500
Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]:5586 "EHLO
	brmx1.fl.icn.siemens.com") by vger.kernel.org with ESMTP
	id <S262859AbSJaSHI>; Thu, 31 Oct 2002 13:07:08 -0500
Message-ID: <180577A42806D61189D30008C7E632E8793B28@boca213a.boca.ssc.siemens.com>
From: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
To: "'Tom Bradley'" <tojabr@tojabr.com>
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail
Date: Thu, 31 Oct 2002 13:13:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Thanks very much.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Tom Bradley [mailto:tojabr@tojabr.com]
Sent: Thursday, October 31, 2002 1:00 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


They are just regular values. The UL tells the compiler to format the
number as an unsgned long.


On Thu, 31 Oct 2002, Bloch, Jack wrote:

> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL.  I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266041AbSKLBcs>; Mon, 11 Nov 2002 20:32:48 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S266042AbSKLBcs>; Mon, 11 Nov 2002 20:32:48 -0500
Received: from 1-064.ctame701-1.telepar.net.br ([200.181.137.64]:14779 "EHLO
	1-064.ctame701-1.telepar.net.br") by vger.kernel.org with ESMTP
	id <S266041AbSKLBcr>; Mon, 11 Nov 2002 20:32:47 -0500
Date: Mon, 11 Nov 2002 23:39:17 -0200 (BRST)
From: Rik van Riel <riel@conectiva.com.br>
X-X-Sender: riel@imladris.surriel.com
To: davidm@hpl.hp.com
cc: Mario Smarduch <cms063@email.mot.com>, <linux-ia64@linuxia64.org>,
       <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <15824.915.758329.73126@napali.hpl.hp.com>
Message-ID: <Pine.LNX.4.44L.0211112337520.3817-100000@imladris.surriel.com>
X-spambait: aardvark@kernelnewbies.org
X-spammeplease: aardvark@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 11 Nov 2002, David Mosberger wrote:
> >>>>> On Mon, 11 Nov 2002 10:29:29 -0600, Mario Smarduch <cms063@email.mot.com> said:
>
>   Mario> I know that on some commercial Unix systems there are ways to
>   Mario> cap the CPU utilization by user/group ids are there such
>   Mario> features/patches available on Linux?

> The kernel patches available from this URL are pretty old (up to
> 2.4.6, as far as I could see), and I'm not sure what the future plans
> for PRM on Linux are.  Perhaps someone else can provide more details.

I'm (slowly) working on a per-user fair scheduler on top of Ingo's
O(1) scheduler.  Slowly because it's a fairly complex thing.

Once that is done it should be possible to change the accounting
to other resource containers and generally have fun assigning
priorities, though that is beyond the scope of what I'm trying to
achieve.

cheers,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267631AbTAMQ2g>; Mon, 13 Jan 2003 11:28:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267828AbTAMQ2g>; Mon, 13 Jan 2003 11:28:36 -0500
Received: from nat-pool-rdu.redhat.com ([66.187.233.200]:65392 "EHLO
	devserv.devel.redhat.com") by vger.kernel.org with ESMTP
	id <S267631AbTAMQ2e>; Mon, 13 Jan 2003 11:28:34 -0500
Date: Mon, 13 Jan 2003 11:37:21 -0500
From: Pete Zaitcev <zaitcev@redhat.com>
To: =?iso-8859-1?Q?Philip_K=2EF=2E_H=F6lzenspies?= 
	<p.k.f.holzenspies@student.utwente.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030113113721.A18786@devserv.devel.redhat.com>
References: <000001c2ba3e$84695730$53a85982@tomwaits>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <000001c2ba3e$84695730$53a85982@tomwaits>; from p.k.f.holzenspies@student.utwente.nl on Sun, Jan 12, 2003 at 02:28:35PM +0100
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11 18:46:51 CET 2003
> Intel MultiProcessor Specification v1.4
>     Virtual Wire compatibility mode.
>[...]
> PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
> PCI->APIC IRQ transform: (B1,I5,P0) -> 16
> PCI->APIC IRQ transform: (B2,I5,P0) -> 18

> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.

I am sorry to say, I cannot help you. This is the department
of Manfred, most likely. The 95% bet is that your BIOS is crap,
and you have to poke ASUS. However, you might want to explore
a possiblity of a bug. The best way to do it is to run "mptable"
program to dump the table and then get someone who makes
a sense of the data. Try to figure out who wrote the code
to support AMD IRQ router. He may be the culprit (5%, but...)

 http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.i386.rpm
 http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.src.rpm

-- Pete

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267541AbTAXFPU>; Fri, 24 Jan 2003 00:15:20 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267542AbTAXFPU>; Fri, 24 Jan 2003 00:15:20 -0500
Received: from [209.195.52.120] ([209.195.52.120]:49808 "HELO
	warden2.diginsite.com") by vger.kernel.org with SMTP
	id <S267541AbTAXFPT>; Fri, 24 Jan 2003 00:15:19 -0500
From: David Lang <david.lang@digitalinsight.com>
To: "Anoop J." <cs99001@nitc.ac.in>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Date: Thu, 23 Jan 2003 21:11:10 -0800 (PST)
Subject: Re: your mail
In-Reply-To: <40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in>
Message-ID: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

The idea of page coloring is based on the fact that common implementations
of caching can't put any page in memory in any line in the cache (such an
implementation is possible, but is more expensive to do so is not commonly
done)

With this implementation it means that if your program happens to use
memory that cannot be mapped to half of the cache lines then effectivly
the CPU cache is half it's rated size for your program. the next time your
program runs it may get a more favorable memory allocation and be able to
use all of the cache and therefor run faster.

Page coloring is an attampt to take this into account when allocating
memory to programs so that every program gets to use all of the cache.

David Lang


 On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>
>
> How does page coloring work. Iwant its mechanism not the implementation.
> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> able to grasp it .
>
>
> Thanks in advance
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267546AbTAXF5g>; Fri, 24 Jan 2003 00:57:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267547AbTAXF5g>; Fri, 24 Jan 2003 00:57:36 -0500
Received: from otter.mbay.net ([206.55.237.2]:48902 "EHLO otter.mbay.net")
	by vger.kernel.org with ESMTP id <S267546AbTAXF5f> convert rfc822-to-8bit;
	Fri, 24 Jan 2003 00:57:35 -0500
From: John Alvord <jalvo@mbay.net>
To: David Lang <david.lang@digitalinsight.com>
Cc: "Anoop J." <cs99001@nitc.ac.in>, linux-kernel@vger.kernel.org,
       linux-mm@kvack.org
Subject: Re: your mail
Date: Thu, 23 Jan 2003 22:06:24 -0800
Message-ID: <csl13vsmj20pfasoh5v4mmv5mv3chqm53m@4ax.com>
References: <40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in> <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
In-Reply-To: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
X-Mailer: Forte Agent 1.92/32.570
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

The big challenge in Linux is that several serious attempts to add
page coloring have foundered on the shoals of "no benefit found". It
may be that the typical hardware Linux runs on just doesn't experience
the problem very much.

john


On Thu, 23 Jan 2003 21:11:10 -0800 (PST), David Lang
<david.lang@digitalinsight.com> wrote:

>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>> How does page coloring work. Iwant its mechanism not the implementation.
>> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>> able to grasp it .
>>
>>
>> Thanks in advance
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267566AbTAXGcz>; Fri, 24 Jan 2003 01:32:55 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267568AbTAXGcz>; Fri, 24 Jan 2003 01:32:55 -0500
Received: from warden-p.diginsite.com ([208.29.163.248]:23807 "HELO
	warden.diginsite.com") by vger.kernel.org with SMTP
	id <S267566AbTAXGcx>; Fri, 24 Jan 2003 01:32:53 -0500
From: David Lang <david.lang@digitalinsight.com>
To: "Anoop J." <cs99001@nitc.ac.in>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date: Thu, 23 Jan 2003 22:28:40 -0800 (PST)
Subject: Re: your mail
In-Reply-To: <42636.210.212.228.78.1043387664.webmail@mail.nitc.ac.in>
Message-ID: <Pine.LNX.4.44.0301232225030.10187-100000@dlang.diginsite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

implementing a fully associative cache eliminates the need for page
coloring, but it has to be implemented in hardware. if you don't have
fully associative caches in your hardware page coloring helps avoid the
worst case memory allocations.

from what I have seen on the attempts to implement it the problem is that
the calculations needed to do page colored allocations end up costing
enough that they end up with a net loss compared to the old method.

David Lang


 On Fri, 24 Jan 2003, Anoop J.
wrote:

> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>
>
> How is this different from a fully associative cache .Would be better if u
> could deal it based on the address bits used
>
> Thanks
>
> David Lang wrote:
>
> >The idea of page coloring is based on the fact that common implementations
> >of caching can't put any page in memory in any line in the cache (such an
> >implementation is possible, but is more expensive to do so is not commonly
> >done)
> >
> >With this implementation it means that if your program happens to use
> >memory that cannot be mapped to half of the cache lines then effectivly
> >the CPU cache is half it's rated size for your program. the next time your
> >program runs it may get a more favorable memory allocation and be able to
> >use all of the cache and therefor run faster.
> >
> >Page coloring is an attampt to take this into account when allocating
> >memory to programs so that every program gets to use all of the cache.
> >
> >David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J. wrote:
> >
> >>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> >>From: Anoop J. <cs99001@nitc.ac.in>
> >>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
> >>
> >>
> >>How does page coloring work. Iwant its mechanism not the implementation.
> >>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> >>able to grasp it .
> >>
> >>
> >>Thanks in advance
> >>
> >>
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267599AbTAXIlq>; Fri, 24 Jan 2003 03:41:46 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267602AbTAXIlq>; Fri, 24 Jan 2003 03:41:46 -0500
Received: from [210.212.228.4] ([210.212.228.4]:37304 "EHLO cnet.nitc.ac.in")
	by vger.kernel.org with ESMTP id <S267599AbTAXIlp>;
	Fri, 24 Jan 2003 03:41:45 -0500
Message-ID: <54208.210.212.228.78.1043398260.webmail@mail.nitc.ac.in>
Date: Fri, 24 Jan 2003 14:21:00 +0530 (IST)
Subject: Re: your mail
From: "Anoop J." <cs99001@nitc.ac.in>
To: <david.lang@digitalinsight.com>
In-Reply-To: <Pine.LNX.4.44.0301232225030.10187-100000@dlang.diginsite.com>
References: <42636.210.212.228.78.1043387664.webmail@mail.nitc.ac.in>
        <Pine.LNX.4.44.0301232225030.10187-100000@dlang.diginsite.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
X-Mailer: nitc webmail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

I read that the data coherency problem due to virtual indexing is avoided
through page coloring and it has also got the speed of physical indexing
can u just elaborate on how this is possible?


Thanks




> implementing a fully associative cache eliminates the need for page
> coloring, but it has to be implemented in hardware. if you don't have
> fully associative caches in your hardware page coloring helps avoid the
> worst case memory allocations.
>
> from what I have seen on the attempts to implement it the problem is
> that the calculations needed to do page colored allocations end up
> costing enough that they end up with a net loss compared to the old
> method.
>
> David Lang
>
>
>  On Fri, 24 Jan 2003, Anoop J.
> wrote:
>
>> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>>
>>
>> How is this different from a fully associative cache .Would be better
>> if u could deal it based on the address bits used
>>




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267608AbTAXIwv>; Fri, 24 Jan 2003 03:52:51 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267609AbTAXIwv>; Fri, 24 Jan 2003 03:52:51 -0500
Received: from [209.195.52.120] ([209.195.52.120]:684 "HELO
	warden2.diginsite.com") by vger.kernel.org with SMTP
	id <S267608AbTAXIwu>; Fri, 24 Jan 2003 03:52:50 -0500
From: David Lang <david.lang@digitalinsight.com>
To: "Anoop J." <cs99001@nitc.ac.in>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date: Fri, 24 Jan 2003 00:48:39 -0800 (PST)
Subject: Re: your mail
In-Reply-To: <54208.210.212.228.78.1043398260.webmail@mail.nitc.ac.in>
Message-ID: <Pine.LNX.4.44.0301240046580.10187-100000@dlang.diginsite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

I think this is a case of the same tuerm being used for two different
purposes. I don't know the use you are refering to.

David Lang


On Fri, 24 Jan 2003, Anoop J. wrote:

> I read that the data coherency problem due to virtual indexing is avoided
> through page coloring and it has also got the speed of physical indexing
> can u just elaborate on how this is possible?
>
>
> Thanks
>
>
>
>
> > implementing a fully associative cache eliminates the need for page
> > coloring, but it has to be implemented in hardware. if you don't have
> > fully associative caches in your hardware page coloring helps avoid the
> > worst case memory allocations.
> >
> > from what I have seen on the attempts to implement it the problem is
> > that the calculations needed to do page colored allocations end up
> > costing enough that they end up with a net loss compared to the old
> > method.
> >
> > David Lang
> >
> >
> >  On Fri, 24 Jan 2003, Anoop J.
> > wrote:
> >
> >> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> >> From: Anoop J. <cs99001@nitc.ac.in>
> >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> >>
> >>
> >> How is this different from a fully associative cache .Would be better
> >> if u could deal it based on the address bits used
> >>
>
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267617AbTAXJkC>; Fri, 24 Jan 2003 04:40:02 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267618AbTAXJkC>; Fri, 24 Jan 2003 04:40:02 -0500
Received: from [210.212.228.4] ([210.212.228.4]:46009 "EHLO cnet.nitc.ac.in")
	by vger.kernel.org with ESMTP id <S267617AbTAXJkB>;
	Fri, 24 Jan 2003 04:40:01 -0500
Message-ID: <57047.210.212.228.78.1043401756.webmail@mail.nitc.ac.in>
Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
Subject: Re: your mail
From: "Anoop J." <cs99001@nitc.ac.in>
To: <david.lang@digitalinsight.com>
In-Reply-To: <Pine.LNX.4.44.0301240046580.10187-100000@dlang.diginsite.com>
References: <54208.210.212.228.78.1043398260.webmail@mail.nitc.ac.in>
        <Pine.LNX.4.44.0301240046580.10187-100000@dlang.diginsite.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
X-Mailer: nitc webmail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

ok i shall put it in another way
since virtual indexing is a representation of the virtual memory,
it is possible for more multiple virtual addresses to represent the same
physical address.So the problem of aliasing occurs in the cache.Does page
coloring guarantee a unique mapping of physical address.If so how is the
maping from virtual to physical address



Thanks



> I think this is a case of the same tuerm being used for two different
> purposes. I don't know the use you are refering to.
>
> David Lang
>
>
>





From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262380AbTAXTTC>; Fri, 24 Jan 2003 14:19:02 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S262500AbTAXTTB>; Fri, 24 Jan 2003 14:19:01 -0500
Received: from warden-p.diginsite.com ([208.29.163.248]:39119 "HELO
	warden.diginsite.com") by vger.kernel.org with SMTP
	id <S262380AbTAXTTB>; Fri, 24 Jan 2003 14:19:01 -0500
From: David Lang <david.lang@digitalinsight.com>
To: "Anoop J." <cs99001@nitc.ac.in>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date: Fri, 24 Jan 2003 11:14:50 -0800 (PST)
Subject: Re: your mail
In-Reply-To: <57047.210.212.228.78.1043401756.webmail@mail.nitc.ac.in>
Message-ID: <Pine.LNX.4.44.0301241110470.10187-100000@dlang.diginsite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

the cache never sees the virtual addresses, it operated excclusivly on the
physical addresses so the problem of aliasing never comes up.

virtual to physical addres mapping is all resolved before anything hits
the cache.

David Lang

On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: david.lang@digitalinsight.com
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> ok i shall put it in another way
> since virtual indexing is a representation of the virtual memory,
> it is possible for more multiple virtual addresses to represent the same
> physical address.So the problem of aliasing occurs in the cache.Does page
> coloring guarantee a unique mapping of physical address.If so how is the
> maping from virtual to physical address
>
>
>
> Thanks
>
>
>
> > I think this is a case of the same tuerm being used for two different
> > purposes. I don't know the use you are refering to.
> >
> > David Lang
> >
> >
> >
>
>
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S264620AbTAXTb3>; Fri, 24 Jan 2003 14:31:29 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S264010AbTAXTb3>; Fri, 24 Jan 2003 14:31:29 -0500
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:36779 "EHLO
	delta.ds2.pg.gda.pl") by vger.kernel.org with ESMTP
	id <S264620AbTAXTb2>; Fri, 24 Jan 2003 14:31:28 -0500
Date: Fri, 24 Jan 2003 20:40:04 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Lang <david.lang@digitalinsight.com>
cc: "Anoop J." <cs99001@nitc.ac.in>, linux-mm@kvack.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.44.0301241110470.10187-100000@dlang.diginsite.com>
Message-ID: <Pine.GSO.3.96.1030124203425.6763A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 24 Jan 2003, David Lang wrote:

> the cache never sees the virtual addresses, it operated excclusivly on the
> physical addresses so the problem of aliasing never comes up.

 It depends on the implementation.

> virtual to physical addres mapping is all resolved before anything hits
> the cache.

 It depends on the processor.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266020AbTAYCJZ>; Fri, 24 Jan 2003 21:09:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S266064AbTAYCJZ>; Fri, 24 Jan 2003 21:09:25 -0500
Received: from boo-mda02.boo.net ([216.200.67.22]:25353 "EHLO
	boo-mda02.boo.net") by vger.kernel.org with ESMTP
	id <S266020AbTAYCJZ>; Fri, 24 Jan 2003 21:09:25 -0500
Message-Id: <3.0.6.32.20030124212935.007fcc10@boo.net>
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 24 Jan 2003 21:29:35 -0500
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
From: Jason Papadopoulos <jasonp@boo.net>
Subject: Re: your mail
In-Reply-To: <csl13vsmj20pfasoh5v4mmv5mv3chqm53m@4ax.com>
References: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
 <40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in>
 <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

At 10:06 PM 1/23/03 -0800, John Alvord wrote:

>The big challenge in Linux is that several serious attempts to add
>page coloring have foundered on the shoals of "no benefit found". It
>may be that the typical hardware Linux runs on just doesn't experience
>the problem very much.

Another strike against page coloring is that it gives tremendous benefits
when caches are large and not very associative, but if both of these are
not present the benefits are much smaller. In the case of latter-day PCs,
neither of these is the case: the caches are very small and at least 8-way
set associative.

For the record, I finally got to try my own page coloring patch on a 1GHz
Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
own number crunching benchmarks and a kernel compile don't show any benefit 
at all, and lmbench is completely unchanged except for the mmap latency, 
which is slightly worse. Hardly a compelling case for PCs!

Oh well. At least now I'll be able to port to 2.5 :)

jasonp

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266064AbTAYCRm>; Fri, 24 Jan 2003 21:17:42 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S266078AbTAYCRm>; Fri, 24 Jan 2003 21:17:42 -0500
Received: from bitmover.com ([192.132.92.2]:59094 "EHLO mail.bitmover.com")
	by vger.kernel.org with ESMTP id <S266064AbTAYCRm>;
	Fri, 24 Jan 2003 21:17:42 -0500
Date: Fri, 24 Jan 2003 18:26:48 -0800
From: Larry McVoy <lm@bitmover.com>
To: Jason Papadopoulos <jasonp@boo.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: your mail
Message-ID: <20030125022648.GA13989@work.bitmover.com>
Mail-Followup-To: Larry McVoy <lm@work.bitmover.com>,
	Jason Papadopoulos <jasonp@boo.net>, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
References: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com> <40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in> <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com> <3.0.6.32.20030124212935.007fcc10@boo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3.0.6.32.20030124212935.007fcc10@boo.net>
User-Agent: Mutt/1.4i
X-MailScanner: Found to be clean
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> For the record, I finally got to try my own page coloring patch on a 1GHz
> Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> own number crunching benchmarks and a kernel compile don't show any benefit 
> at all, and lmbench is completely unchanged except for the mmap latency, 
> which is slightly worse. Hardly a compelling case for PCs!

If it works correctly then the variability in lat_ctx should go away.
Try this

	for p in 2 4 8 12 16 24 32 64
	do	for size in 0 2 4 8 16
		do	for i in 1 2 3 4 5 6 7 8 9 0
			do	lat_ctx -s$size $p
			done
		done
	done

on both the with and without kernel.  The page coloring should make the 
numbers rock steady, without it, they will bounce a lot.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261624AbTAYRix>; Sat, 25 Jan 2003 12:38:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261645AbTAYRiw>; Sat, 25 Jan 2003 12:38:52 -0500
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:55114 "EHLO
	frodo.biederman.org") by vger.kernel.org with ESMTP
	id <S261624AbTAYRiv>; Sat, 25 Jan 2003 12:38:51 -0500
To: Larry McVoy <lm@bitmover.com>
Cc: Jason Papadopoulos <jasonp@boo.net>, linux-kernel@vger.kernel.org,
       linux-mm@kvack.org
Subject: Re: your mail
References: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
	<40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in>
	<Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
	<3.0.6.32.20030124212935.007fcc10@boo.net>
	<20030125022648.GA13989@work.bitmover.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: 25 Jan 2003 10:47:19 -0700
In-Reply-To: <20030125022648.GA13989@work.bitmover.com>
Message-ID: <m17kctceag.fsf@frodo.biederman.org>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Larry McVoy <lm@bitmover.com> writes:

> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit 
> > at all, and lmbench is completely unchanged except for the mmap latency, 
> > which is slightly worse. Hardly a compelling case for PCs!
> 
> If it works correctly then the variability in lat_ctx should go away.
> Try this
> 
> 	for p in 2 4 8 12 16 24 32 64
> 	do	for size in 0 2 4 8 16
> 		do	for i in 1 2 3 4 5 6 7 8 9 0
> 			do	lat_ctx -s$size $p
> 			done
> 		done
> 	done
> 
> on both the with and without kernel.  The page coloring should make the 
> numbers rock steady, without it, they will bounce a lot.

On the same kind of vein I have seen some tremendous variability in the
stream benchmark.  Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs.  In one case
it ran faster with updatedb running in the background.

But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.

So I do no the variables of cache contention do have effect on some
real programs.  I have not yet tracked it down to see if cache coloring
could be a benefit.  I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.

I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S262780AbTAYXBm>; Sat, 25 Jan 2003 18:01:42 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S264001AbTAYXBm>; Sat, 25 Jan 2003 18:01:42 -0500
Received: from bitmover.com ([192.132.92.2]:47332 "EHLO mail.bitmover.com")
	by vger.kernel.org with ESMTP id <S262780AbTAYXBl>;
	Sat, 25 Jan 2003 18:01:41 -0500
Date: Sat, 25 Jan 2003 15:10:50 -0800
From: Larry McVoy <lm@bitmover.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Larry McVoy <lm@bitmover.com>, Jason Papadopoulos <jasonp@boo.net>,
       linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: your mail
Message-ID: <20030125231050.GA21095@work.bitmover.com>
Mail-Followup-To: Larry McVoy <lm@work.bitmover.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Larry McVoy <lm@bitmover.com>, Jason Papadopoulos <jasonp@boo.net>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
References: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com> <40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in> <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com> <3.0.6.32.20030124212935.007fcc10@boo.net> <20030125022648.GA13989@work.bitmover.com> <m17kctceag.fsf@frodo.biederman.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m17kctceag.fsf@frodo.biederman.org>
User-Agent: Mutt/1.4i
X-MailScanner: Found to be clean
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I am wondering if there is any point in biasing page addresses in between
> processes so that processes are less likely to have a cache conflict.
> i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

All good page coloring implementation do exactly that.  The starting
index into the page buckets is based on process id.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266717AbTAZHXk>; Sun, 26 Jan 2003 02:23:40 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S266730AbTAZHXk>; Sun, 26 Jan 2003 02:23:40 -0500
Received: from rth.ninka.net ([216.101.162.244]:8880 "EHLO rth.ninka.net")
	by vger.kernel.org with ESMTP id <S266717AbTAZHXj>;
	Sun, 26 Jan 2003 02:23:39 -0500
Subject: Re: your mail
From: "David S. Miller" <davem@redhat.com>
To: Larry McVoy <lm@bitmover.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
       Jason Papadopoulos <jasonp@boo.net>, linux-kernel@vger.kernel.org,
       linux-mm@kvack.org
In-Reply-To: <20030125231050.GA21095@work.bitmover.com>
References: <Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
	<40475.210.212.228.78.1043384883.webmail@mail.nitc.ac.in>
	<Pine.LNX.4.44.0301232104440.10187-100000@dlang.diginsite.com>
	<3.0.6.32.20030124212935.007fcc10@boo.net>
	<20030125022648.GA13989@work.bitmover.com>
	<m17kctceag.fsf@frodo.biederman.org> 
	<20030125231050.GA21095@work.bitmover.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 26 Jan 2003 00:12:03 -0800
Message-Id: <1043568723.4096.2.camel@rth.ninka.net>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 2003-01-25 at 15:10, Larry McVoy wrote:
> All good page coloring implementation do exactly that.  The starting
> index into the page buckets is based on process id.

I think everyone interested in learning more about this
topic should go read the following papers, they were very
helpful when I was fiddling around in this area.

These papers, in turn, reference several others which are
good reads as well.

1) W. L. Lynch, B. K. Bray, and M. J. Flynn. "The effect of page
   allocation on caches". In Micro-25 Conference Proceedings, pages
   222-225, December 1992. 

2) W. Lynch and M. Flynn. "Cache improvements through colored page
   allocation". ACM Transactions on Computer Systems, 1993. Submitted
   for review, 1992. 

3) William L. Lynch. "The Interaction of Virtual Memory and Cache
   Memory". PhD thesis, Stanford University, October
   1993. CSL-TR-93-587.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S266318AbTBCNqa>; Mon, 3 Feb 2003 08:46:30 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S266320AbTBCNqa>; Mon, 3 Feb 2003 08:46:30 -0500
Received: from [195.20.32.236] ([195.20.32.236]:31927 "HELO euro.verza.com")
	by vger.kernel.org with SMTP id <S266318AbTBCNqU>;
	Mon, 3 Feb 2003 08:46:20 -0500
Date: Mon, 3 Feb 2003 13:53:52 +0100
From: Alexander Kellett <lypanov@kde.org>
To: saurabh khanna <linux_guyus@rediffmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030203125352.GA5925@groucho.verza.com>
Mail-Followup-To: saurabh khanna <linux_guyus@rediffmail.com>,
	linux-kernel@vger.kernel.org
References: <20030131184605.22113.qmail@webmail29.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030131184605.22113.qmail@webmail29.rediffmail.com>
User-Agent: Mutt/1.4i
Disclaimer: My opinions do not necessarily represent those of my employer
Copyright: Copyright 2003 Alexander Kellett - All Rights Reserved
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

hiya,

unfortunately this list isn't for such problems and it
would be better to contact your distribution or the various
forums it has. try google.

/me wonders again why this list isn't called linux-kernel-dev@...

Alex

On Fri, Jan 31, 2003 at 06:46:05PM -0000, saurabh  khanna wrote:
> Problem: My xwindows did not open and my sound card don't work.
> 
> Xwindows:
> I am a novice. I am using redhat linux 8. It detects my graphics 
> card
> correctly but when i tried to open xwindows, my system hangs.
> 
> Sound:
> Linux has detected my sound card once but not configured it and 
> after
> that nor it is working nither it is detected by my linux.
> 
> GRUB:
> Also, i can boot my linux through LILO only. GRUB wont work, it 
> gives
> error "Not enough memory".
> 
> I have re-installed linux on my computer but the problem 
> remains.
> All other detailes are follows.
> 
> Kernel version:
> Linux version 2.4.18-14 (bhcompile@astest.test.redhat.com)
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7))
> #1 Wed Sep 4 12:13:11 EDT 2002
> 
> 
> Commond which triggers the problem:
> startx
> 
> Processor information:
> processor	: 0
> 
> vendor_id	: AuthenticAMD
> 
> cpu family	: 6
> 
> model		: 6
> 
> model name	: AMD Athlon(TM) XP 1700+
> 
> stepping	: 2
> 
> cpu MHz		: 1469.861
> 
> cache size	: 256 KB
> 
> fdiv_bug	: no
> 
> hlt_bug		: no
> 
> f00f_bug	: no
> 
> coma_bug	: no
> 
> fpu		: yes
> 
> fpu_exception	: yes
> 
> cpuid level	: 1
> 
> wp		: yes
> 
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
> 
> bogomips	: 2920.57
> 
> 
> 
> Module information:
> nls_iso8859-1           3516   1 (autoclean)
> 
> nls_cp437               5116   1 (autoclean)
> 
> vfat                   13084   1 (autoclean)
> 
> fat                    38744   0 (autoclean)
> [vfat]
> autofs                 13348   0 (autoclean) (unused)
> 
> ipt_REJECT              3736   2 (autoclean)
> 
> iptable_filter          2412   1 (autoclean)
> 
> ip_tables              14840   2 [ipt_REJECT iptable_filter]
> 
> mousedev                5524   0 (unused)
> 
> keybdev                 2976   0 (unused)
> 
> hid                    22244   0 (unused)
> 
> input                   5888   0 [mousedev keybdev hid]
> 
> usb-ohci               21288   0 (unused)
> 
> usbcore                77056   1 [hid usb-ohci]
> 
> ext3                   70400   1
> 
> jbd                    52212   1 [ext3]
> 
> 
> 
> Loaded driver and hardware information:
> 0000-001f : dma
> 1
> 0020-003f : pic
> 1
> 0040-005f : timer
> 
> 0060-006f : keyboard
> 
> 0070-007f : rtc
> 
> 0080-008f : dma page reg
> 
> 00a0-00bf : pic
> 2
> 00c0-00df : dma
> 2
> 00f0-00ff : fpu
> 
> 01f0-01f7 : ide
> 0
> 02f8-02ff : serial(auto)
> 
> 03c0-03df : vga+
> 
> 03f6-03f6 : ide
> 0
> 03f8-03ff : serial(auto)
> 
> 0cf8-0cff : PCI conf
> 1
> 5000-500f : PCI device 10de:01b4 (nVidia Corporation)
> 
> 5100-511f : PCI device 10de:01b4 (nVidia Corporation)
> 
> 5500-550f : PCI device 10de:01b4 (nVidia Corporation)
> 
> a800-a80f : nVidia Corporation nForce IDE
> 
> a800-a807 : ide0
> 
> a808-a80f : ide1
> 
> b000-bfff : PCI Bus #01
> 
> b800-b807 : Rockwell International HCF 56k Data/Fax/Voice/Spkp 
> (w/Handset) Modem
> 
> d800-d807 : PCI device 10de:01c3 (nVidia Corporation)
> 
> e000-e07f : PCI device 10de:01b1 (nVidia Corporation)
> 
> e100-e1ff : PCI device 10de:01b1 (nVidia Corporation)
> 
> 00000000-0007ffff : System RAM
> 
> 0009fc00-0009ffff : reserved
> 
> 000a0000-000bffff : Video RAM area
> 
> 000c0000-000c7fff : Video ROM
> 
> 000f0000-000fffff : System ROM
> 
> 00100000-06febfff : System RAM
> 
> 00100000-00247f2e : Kernel code
> 
> 00247f2f-0033ed03 : Kernel data
> 
> 06fec000-06feefff : ACPI Tables
> 
> 06fef000-06ffefff : reserved
> 
> 06fff000-06ffffff : ACPI Non-volatile Storage
> 
> eb000000-ec7fffff : PCI Bus #02
> 
> eb000000-ebffffff : nVidia Corporation GeForce2 Integrated GPU
> 
> ec800000-ecffffff : PCI Bus #01
> 
> ec800000-ec80ffff : Rockwell International HCF 56k 
> Data/Fax/Voice/Spkp (w/Handset) Modem
> 
> ed000000-ed000fff : PCI device 10de:01b1 (nVidia Corporation)
> 
> ed800000-ed87ffff : PCI device 10de:01b0 (nVidia Corporation)
> 
> ee000000-ee0003ff : PCI device 10de:01c3 (nVidia Corporation)
> 
> ee800000-ee800fff : PCI device 10de:01c2 (nVidia Corporation)
> 
> ee800000-ee800fff : usb-ohci
> e
> f000000-ef000fff : PCI device
> 10de:01c2 (nVidia Corporation)
> 
> ef000000-ef000fff : usb-ohci
> e
> ff00000-f7ffffff : PCI Bus #02
> 
> f0000000-f7ffffff : nVidia Corporation GeForce2 Integrated GPU
> 
> f8000000-fbffffff : PCI device
> 10de:01a4 (nVidia Corporation)
> 
> fec00000-fec00fff : reserved
> 
> fee00000-fee00fff : reserved
> 
> ffff0000-ffffffff : reserved
> 
> 
> PCI information:
> 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev 
> b2)
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
> 	Capabilities: [40] AGP version 2.0
> 		Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
> 		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x1
> 	Capabilities: [60] #08 [2001]
> 
> 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory 
> Controller (rev b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory 
> Controller (rev b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:00.3 RAM memory: nVidia Corporation: Unknown device 01aa (rev 
> b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev 
> c3)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Capabilities: [50] #08 [01e1]
> 
> 00:01.1 SMBus: nVidia Corporation nForce PCI System Management 
> (rev c1)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: I/O ports at 5000 [size=16]
> 	Region 1: I/O ports at 5500 [size=16]
> 	Region 2: I/O ports at 5100 [size=32]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:02.0 USB Controller: nVidia Corporation: Unknown device 01c2 
> (rev c3) (prog-if 10 [OHCI])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ef000000 (32-bit, non-prefetchable) 
> [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:03.0 USB Controller: nVidia Corporation: Unknown device 01c2 
> (rev c3) (prog-if 10 [OHCI])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ee800000 (32-bit, non-prefetchable) 
> [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:04.0 Ethernet controller: nVidia Corporation: Unknown device 
> 01c3 (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (250ns min, 5000ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ee000000 (32-bit, non-prefetchable) 
> [size=1K]
> 	Region 1: I/O ports at d800 [size=8]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:05.0 Multimedia audio controller: nVidia Corporation: Unknown 
> device 01b0 (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (250ns min, 3000ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ed800000 (32-bit, non-prefetchable) 
> [size=512K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:06.0 Multimedia audio controller: nVidia Corporation nForce 
> Audio (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 8384
> 	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (500ns min, 1250ns max)
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: I/O ports at e100 [size=256]
> 	Region 1: I/O ports at e000 [size=128]
> 	Region 2: Memory at ed000000 (32-bit, non-prefetchable) 
> [disabled] [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge 
> (rev c2) (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 0000b000-0000bfff
> 	Memory behind bridge: ec800000-ecffffff
> 	Prefetchable memory behind bridge: f8000000-f7ffffff
> 	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> 
> 00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) 
> (prog-if 8a [Master SecP PriP])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Region 4: I/O ports at a800 [size=16]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge 
> (rev b2) (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
> 	I/O behind bridge: 0000a000-00009fff
> 	Memory behind bridge: eb000000-ec7fffff
> 	Prefetchable memory behind bridge: eff00000-f7ffffff
> 	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
> 
> 01:08.0 Communication controller: Rockwell International HCF 56k 
> Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)
> 	Subsystem: Rockwell International HCF 56k Data/Fax/Voice/Spkp 
> (w/Handset) Modem
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 64
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ec800000 (32-bit, non-prefetchable) 
> [size=64K]
> 	Region 1: I/O ports at b800 [size=8]
> 	Capabilities: [40] Power Management version 2
> 		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
> 
> 02:00.0 VGA compatible controller: nVidia Corporation NV15 
> [GeForce2 - nForce GPU] (rev b1) (prog-if 00 [VGA])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 32 (1250ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at eb000000 (32-bit, non-prefetchable) 
> [size=16M]
> 	Region 1: Memory at f0000000 (32-bit, prefetchable) 
> [size=128M]
> 	Expansion ROM at efff0000 [disabled] [size=64K]
> 	Capabilities: [60] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [44] AGP version 2.0
> 		Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x4
> 		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
> 
> 
> 
> XF86Config:
> 
> # File generated by anaconda.
> 
> Section "ServerLayout"
>         Identifier     "Anaconda Configured"
>         Screen      0  "Screen0" 0 0
>         InputDevice    "Mouse0" "CorePointer"
> 	InputDevice	"Mouse1" "SendCoreEvents"
>         InputDevice    "Keyboard0" "CoreKeyboard"
> EndSection
> 
> Section "Files"
> 
> # The location of the RGB database.  Note, this is the name of 
> the
> # file minus the extension (like ".txt" or ".db").  There is 
> normally
> # no need to change the default.
> 
>     RgbPath	"/usr/X11R6/lib/X11/rgb"
> 
> # Multiple FontPath entries are allowed (they are concatenated 
> together)
> # By default, Red Hat 6.0 and later now use a font server 
> independent of
> # the X server to render fonts.
> 
>     FontPath   "unix/:7100"
> 
> EndSection
> 
> Section "Module"
>         Load  "dbe"
>         Load  "extmod"
> 	Load  "fbdevhw"
> 	Load  "dri"
>         Load  "glx"
>         Load  "record"
>         Load  "freetype"
>         Load  "type1"
> EndSection
> 
> Section "InputDevice"
>         Identifier  "Keyboard0"
>         Driver      "keyboard"
> 
> #	Option	"AutoRepeat"	"500 5"
> 
> # when using XQUEUE, comment out the above line, and uncomment 
> the
> # following line
> #	Option	"Protocol"	"Xqueue"
> 
> # Specify which keyboard LEDs can be user-controlled (eg, with 
> xset(1))
> #	Option	"Xleds"		"1 2 3"
> 
> # To disable the XKEYBOARD extension, uncomment XkbDisable.
> #	Option	"XkbDisable"
> 
> # To customise the XKB settings to suit your keyboard, modify 
> the
> # lines below (which are the defaults).  For example, for a 
> non-U.S.
> # keyboard, you will probably want to use:
> #	Option	"XkbModel"	"pc102"
> # If you have a US Microsoft Natural keyboard, you can use:
> #	Option	"XkbModel"	"microsoft"
> #
> # Then to change the language, change the Layout setting.
> # For example, a german layout can be obtained with:
> #	Option	"XkbLayout"	"de"
> # or:
> #	Option	"XkbLayout"	"de"
> #	Option	"XkbVariant"	"nodeadkeys"
> #
> # If you'd like to switch the positions of your capslock and
> # control keys, use:
> #	Option	"XkbOptions"	"ctrl:swapcaps"
> 	Option	"XkbRules"	"xfree86"
> 	Option	"XkbModel"	"pc105"
> 	Option	"XkbLayout"	"us"
> 	#Option	"XkbVariant"	""
> 	#Option	"XkbOptions"	""
> EndSection
> 
> Section "InputDevice"
>         Identifier  "Mouse0"
>         Driver      "mouse"
>         Option      "Protocol" "PS/2"
>         Option      "Device" "/dev/psaux"
>         Option      "ZAxisMapping" "4 5"
>         Option      "Emulate3Buttons" "yes"
> EndSection
> 
> 
> Section "InputDevice"
> 	Identifier	"Mouse1"
> 	Driver		"mouse"
> 	Option		"Device"		"/dev/input/mice"
> 	Option		"Protocol"		"IMPS/2"
> 	Option		"Emulate3Buttons"	"no"
> 	Option		"ZAxisMapping"		"4 5"
> EndSection
> 
> 
> Section "Monitor"
>         Identifier   "Monitor0"
>         VendorName   "Monitor Vendor"
>         ModelName    "Monitor Model"
>         HorizSync   30-55
>         VertRefresh 50-120
>         Option "dpms"
> 
> 
> EndSection
> 
> Section "Device"
> 	# no known options
> 	Identifier   "NVIDIA GeForce 2 MX (generic)"
>         Driver       "nv"
>         VendorName   "NVIDIA GeForce 2 MX (generic)"
>         BoardName     "NVIDIA GeForce 2 MX (generic)"
> 
>         #BusID
> EndSection
> 
> Section "Screen"
> 	Identifier   "Screen0"
>         Device       "NVIDIA GeForce 2 MX (generic)"
>         Monitor      "Monitor0"
> 	DefaultDepth	16
> 
> 	Subsection "Display"
>         	Depth       16
>                 Modes       "1024x768" "800x600" "640x480"
> 	EndSubsection
> 
> EndSection
> 
> Section "DRI"
> 	Mode 0666
> EndSection
> 
> cmdline:
> auto BOOT_IMAGE=linux ro BOOT_FILE=/boot/vmlinuz-2.4.18-14 
> root=LABEL=/
> 
> 
> dma:
> 4: cascade
> 
> 
> intrrupts:
> CPU0
>   0:     337647          XT-PIC  timer
>   1:       2694          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:          0          XT-PIC  usb-ohci, usb-ohci
>   8:          1          XT-PIC  rtc
>  12:         20          XT-PIC  PS/2 Mouse
>  14:      27338          XT-PIC  ide0
> NMI:          0
> ERR:          2
> 
> 
> partitions:
> major minor  #blocks  name     rio rmerge rsect ruse wio wmerge 
> wsect wuse running use aveq
> 
>    3     0   39121488 hda 2567 4181 52107 22201 1417 1941 26952 
> 45880 -2 329576 7788488
>    3     1    5245191 hda1 9 43 104 109 0 0 0 0 0 109 109
>    3     2          1 hda2 0 0 0 0 0 0 0 0 0 0 0
>    3     5   10490413 hda5 9 43 104 95 0 0 0 0 0 95 95
>    3     6   11695288 hda6 50 43 145 214 7 1 8 95 0 230 310
>    3     7    8104761 hda7 9 43 104 132 0 0 0 0 0 132 132
>    3     8    3277228 hda8 2475 3966 51498 21527 1410 1940 26944 
> 45785 0 22394 67314
>    3     9     305203 hda9 9 25 104 56 0 0 0 0 0 56 56
> 
> 
> 
> My e-mail addresses are: linux_guyus@yahoo.com and 
> linux_guyus@rediff.com
> My postel address: 80, Ahilya Nagar Ext. Annapurna Road, Indore, 
> M.P.,
> India. PIN 452009
> please answer me soon.
> 		Thanking you.
> 			Saurabh Khanna.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

mvg,
Alex

-- 
"[...] Konqueror open source project. Weighing in at less than
            one tenth the size of another open source renderer"
Apple,  Jan 2003 (http://www.apple.com/safari/)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263554AbTDCTtq 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 14:49:46 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S263556AbTDCTtp 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 14:49:45 -0500
Received: from chaos.analogic.com ([204.178.40.224]:57751 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id S263554AbTDCTtI 
	(for <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Apr 2003 14:49:08 -0500
Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: "David S. Miller" <davem@redhat.com>
cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <1049397747.12168.1.camel@rth.ninka.net>
Message-ID: <Pine.LNX.4.53.0304031458190.9794@chaos>
References: <Pine.LNX.4.53.0304031113490.5422@chaos> <1049397747.12168.1.camel@rth.ninka.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 3 Apr 2003, David S. Miller wrote:

> On Thu, 2003-04-03 at 08:22, Richard B. Johnson wrote:
> > FYI vger rejects mail sent from yahoo.com, claims that it
> > has a HTML subpart and considers it spam or Outlook Virus.
> >
> > FYI any mail sent from yahoo will end up using the yahoo tools
> > (qmail). This will put an empty HTML section in all mail. It
> > is not a good thing to reject this because that means you reject
> > all mail from yahoo.
>
> That's yahoo users problem not ours.  If you can't be bothered
> to get a plain text email out, you shouldn't be using these
> lists.
>

Well it's not a yahoo users problem because yahoo users can't fix
it. Some yahoo users have yahoo "free" mail as their only connection
to the internet because of facist network administrators. It gets
worse how that you can't tell a company to go screw themselves and
get another job. The three engineers that I know who use yahoo do
so because they don't have any choice and there is no way that they
can configure the mailer to get rid of the empty HTML section.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263463AbTDCT5p 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 14:57:45 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S263432AbTDCTyj 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 14:54:39 -0500
Received: from pizda.ninka.net ([216.101.162.242]:9881 "EHLO pizda.ninka.net")
	by vger.kernel.org with ESMTP id S263428AbTDCTyS 
	(for <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Apr 2003 14:54:18 -0500
Date: Thu, 03 Apr 2003 12:00:46 -0800 (PST)
Message-Id: <20030403.120046.98056137.davem@redhat.com>
To: root@chaos.analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <Pine.LNX.4.53.0304031458190.9794@chaos>
References: <Pine.LNX.4.53.0304031113490.5422@chaos>
	<1049397747.12168.1.camel@rth.ninka.net>
	<Pine.LNX.4.53.0304031458190.9794@chaos>
X-FalunGong: Information control.
X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

   From: "Richard B. Johnson" <root@chaos.analogic.com>
   Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
   
   Well it's not a yahoo users problem because yahoo users can't fix
   it. Some yahoo users have yahoo "free" mail as their only connection
   to the internet because of facist network administrators.

If you want all the SPAM that will result on Linux-kernel, we
can disable the filter if you want.

I refuse to sit here and listen to all the "this is the only
connection person FOO has to the internet" stories, quite frankly I'm
absolutely sick of hearing them.

If you don't have properly functioning mail, you can't use these
lists.

Period.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263416AbTDCUMV 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 15:12:21 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S261515AbTDCUMH 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 15:12:07 -0500
Received: from pizda.ninka.net ([216.101.162.242]:18585 "EHLO pizda.ninka.net")
	by vger.kernel.org with ESMTP id S263593AbTDCUIo 
	(for <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Apr 2003 15:08:44 -0500
Date: Thu, 03 Apr 2003 12:15:14 -0800 (PST)
Message-Id: <20030403.121514.66080276.davem@redhat.com>
To: root@chaos.analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <Pine.LNX.4.53.0304031520120.9911@chaos>
References: <Pine.LNX.4.53.0304031458190.9794@chaos>
	<20030403.120046.98056137.davem@redhat.com>
	<Pine.LNX.4.53.0304031520120.9911@chaos>
X-FalunGong: Information control.
X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

   From: "Richard B. Johnson" <root@chaos.analogic.com>
   Date: Thu, 3 Apr 2003 15:21:25 -0500 (EST)

   On Thu, 3 Apr 2003, David S. Miller wrote:
   
   > If you want all the SPAM that will result on Linux-kernel, we
   > can disable the filter if you want.
   
   No. I think you can let empty HTML sections go through.
   
I think these people who it matters to can petition yahoo.com to drop
this dumb empty HTML section.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261492AbTDCUL6 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 15:11:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S261515AbTDCUL5 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 15:11:57 -0500
Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([213.105.254.86]:50566
	"EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP
	id S261492AbTDCULm 
	(for <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Apr 2003 15:11:42 -0500
Subject: Re: your mail
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: root@chaos.analogic.com
Cc: "David S. Miller" <davem@redhat.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.53.0304031458190.9794@chaos>
References: <Pine.LNX.4.53.0304031113490.5422@chaos>
	 <1049397747.12168.1.camel@rth.ninka.net>
	 <Pine.LNX.4.53.0304031458190.9794@chaos>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1049397860.11747.86.camel@dhcp22.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 03 Apr 2003 20:24:20 +0100
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Iau, 2003-04-03 at 21:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.

There are lots of other free email providers.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263590AbTDCUHY 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 15:07:24 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S263591AbTDCUHX 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 15:07:23 -0500
Received: from chaos.analogic.com ([204.178.40.224]:59543 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP
	id S263590AbTDCUHR 
	(for <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Apr 2003 15:07:17 -0500
Date: Thu, 3 Apr 2003 15:21:25 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: "David S. Miller" <davem@redhat.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20030403.120046.98056137.davem@redhat.com>
Message-ID: <Pine.LNX.4.53.0304031520120.9911@chaos>
References: <Pine.LNX.4.53.0304031113490.5422@chaos> <1049397747.12168.1.camel@rth.ninka.net>
 <Pine.LNX.4.53.0304031458190.9794@chaos> <20030403.120046.98056137.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 3 Apr 2003, David S. Miller wrote:

>    From: "Richard B. Johnson" <root@chaos.analogic.com>
>    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
>
>    Well it's not a yahoo users problem because yahoo users can't fix
>    it. Some yahoo users have yahoo "free" mail as their only connection
>    to the internet because of facist network administrators.
>
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.

No. I think you can let empty HTML sections go through.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263603AbTDCU3x 
	(for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 15:29:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id S263610AbTDCU3x 
	(for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 15:29:53 -0500
Received: from smtp-send.myrealbox.com ([192.108.102.143]:57028 "EHLO
	smtp-send.myrealbox.com") by vger.kernel.org with ESMTP
	id S263603AbTDCU3w 
	(for <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Apr 2003 15:29:52 -0500
Subject: Re: your mail
From: "Trever L. Adams" <tadams-lists@myrealbox.com>
To: root@chaos.analogic.com
Cc: "David S. Miller" <davem@redhat.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.53.0304031458190.9794@chaos>
References: <Pine.LNX.4.53.0304031113490.5422@chaos>
	 <1049397747.12168.1.camel@rth.ninka.net>
	 <Pine.LNX.4.53.0304031458190.9794@chaos>
Content-Type: text/plain
Organization: 
Message-Id: <1049402431.1085.1.camel@aurora.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) 
Date: 03 Apr 2003 15:40:31 -0500
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2003-04-03 at 15:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.

I would suggest that those who think Yahoo is there only option, check
out digitalme.com or myrealbox.com.  Web, pop, imap, etc.  All free.

Trever
--
"Never raise your hand to your children - it leaves your midsection
unprotected." -- Matthew Harrell


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263598AbTDDAUE (for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 19:20:04 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263600AbTDDAUE (for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 19:20:04 -0500
Received: from lrsehosting.com ([198.78.66.31]:27410 "EHLO www.geekizoid.com")
	by vger.kernel.org with ESMTP id S263598AbTDDAT7 (for <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Apr 2003 19:19:59 -0500
Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)
From: William Scott Lockwood III <vlad@geekizoid.com>
To: "David S. Miller" <davem@redhat.com>
cc: root@chaos.analogic.com, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20030403.120046.98056137.davem@redhat.com>
Message-ID: <20030403163038.O49943-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 3 Apr 2003, David S. Miller wrote:
>    From: "Richard B. Johnson" <root@chaos.analogic.com>
>    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
>    Well it's not a yahoo users problem because yahoo users can't fix
>    it. Some yahoo users have yahoo "free" mail as their only connection
>    to the internet because of facist network administrators.
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.
> I refuse to sit here and listen to all the "this is the only
> connection person FOO has to the internet" stories, quite frankly I'm
> absolutely sick of hearing them.
> If you don't have properly functioning mail, you can't use these
> lists.
> Period.

When did that become your call?  I didn't realize you owned LKML.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263601AbTDDAfu (for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 19:35:50 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263602AbTDDAfu (for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 19:35:50 -0500
Received: from lrsehosting.com ([198.78.66.31]:60676 "EHLO www.geekizoid.com")
	by vger.kernel.org with ESMTP id S263601AbTDDAfn (for <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Apr 2003 19:35:43 -0500
Date: Thu, 3 Apr 2003 16:47:09 -0800 (PST)
From: William Scott Lockwood III <vlad@geekizoid.com>
To: "David S. Miller" <davem@redhat.com>
cc: root@chaos.analogic.com, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20030403.164027.52309189.davem@redhat.com>
Message-ID: <20030403164558.H49943-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Yeah, sorry - I thought HPA was running it for some reason.  I still don't
think you should make that kind of a call unilaterally, but hey - after
all the incessant whining I put up with about using OE, I finally caved
and moved to a real email address myself.  I guess it just goes to show
that if you while and act petulant long enough...

On Thu, 3 Apr 2003, David S. Miller wrote:

>    From: William Scott Lockwood III <vlad@geekizoid.com>
>    Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)
>
>    When did that become your call?  I didn't realize you owned LKML.
>
> Maybe this is news to you, but I've been running LKML for
> 6 or so years now.
>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263592AbTDDAeE (for <rfc822;willy@w.ods.org>); Thu, 3 Apr 2003 19:34:04 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263594AbTDDAeE (for <rfc822;linux-kernel-outgoing>); Thu, 3 Apr 2003 19:34:04 -0500
Received: from pizda.ninka.net ([216.101.162.242]:50330 "EHLO pizda.ninka.net")
	by vger.kernel.org with ESMTP id S263592AbTDDAdq (for <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Apr 2003 19:33:46 -0500
Date: Thu, 03 Apr 2003 16:40:27 -0800 (PST)
Message-Id: <20030403.164027.52309189.davem@redhat.com>
To: vlad@geekizoid.com
Cc: root@chaos.analogic.com, linux-kernel@vger.kernel.org
Subject: Re: your mail
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <20030403163038.O49943-100000@www.geekizoid.com>
References: <20030403.120046.98056137.davem@redhat.com>
	<20030403163038.O49943-100000@www.geekizoid.com>
X-FalunGong: Information control.
X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

   From: William Scott Lockwood III <vlad@geekizoid.com>
   Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)

   When did that become your call?  I didn't realize you owned LKML.
   
Maybe this is news to you, but I've been running LKML for
6 or so years now.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263769AbTDDMo6 (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 07:44:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263770AbTDDMo6 (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 07:44:58 -0500
Received: from chaos.analogic.com ([204.178.40.224]:43648 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP id S263769AbTDDMon (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 07:44:43 -0500
Date: Fri, 4 Apr 2003 07:57:40 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: William Scott Lockwood III <vlad@geekizoid.com>
cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20030403163038.O49943-100000@www.geekizoid.com>
Message-ID: <Pine.LNX.4.53.0304040752500.2804@chaos>
References: <20030403163038.O49943-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 3 Apr 2003, William Scott Lockwood III wrote:

> On Thu, 3 Apr 2003, David S. Miller wrote:
> >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> >    Well it's not a yahoo users problem because yahoo users can't fix
> >    it. Some yahoo users have yahoo "free" mail as their only connection
> >    to the internet because of facist network administrators.
> > If you want all the SPAM that will result on Linux-kernel, we
> > can disable the filter if you want.
> > I refuse to sit here and listen to all the "this is the only
> > connection person FOO has to the internet" stories, quite frankly I'm
> > absolutely sick of hearing them.
> > If you don't have properly functioning mail, you can't use these
> > lists.
> > Period.
>
> When did that become your call?  I didn't realize you owned LKML.
>

Well it's his "baseball" and; "You'll play by my rules or you won't
play at all..."

FYI, there is no Major Domo. It's Latin, major domus, "master of
the house". He doith whatever he careth...

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263763AbTDDPWB (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 10:22:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263760AbTDDPUo (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 10:20:44 -0500
Received: from lrsehosting.com ([198.78.66.31]:57871 "EHLO www.geekizoid.com")
	by vger.kernel.org with ESMTP id S263758AbTDDPQs (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 10:16:48 -0500
Date: Fri, 4 Apr 2003 07:28:12 -0800 (PST)
From: William Scott Lockwood III <vlad@geekizoid.com>
To: "Richard B. Johnson" <root@chaos.analogic.com>
cc: "David S. Miller" <davem@redhat.com>, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.53.0304040752500.2804@chaos>
Message-ID: <20030404072327.J5167-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > On Thu, 3 Apr 2003, David S. Miller wrote:
> > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > >    Well it's not a yahoo users problem because yahoo users can't fix
> > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > >    to the internet because of facist network administrators.
> > > If you want all the SPAM that will result on Linux-kernel, we
> > > can disable the filter if you want.
> > > I refuse to sit here and listen to all the "this is the only
> > > connection person FOO has to the internet" stories, quite frankly I'm
> > > absolutely sick of hearing them.
> > > If you don't have properly functioning mail, you can't use these
> > > lists.
> > > Period.
> > When did that become your call?  I didn't realize you owned LKML.
> Well it's his "baseball" and; "You'll play by my rules or you won't
> play at all..."
> FYI, there is no Major Domo. It's Latin, major domus, "master of
> the house". He doith whatever he careth...

Yes, I can see that.  No matter who it alienates.  Weither or not he's
checked with anyone else either.  How about leting those of us who (like
Linus) choose to use a commercial email product do so?  Garbage about
headers, etc. is just that - garbage.  The best list is one that is
inclusive.  One that tollerates other opinions and choices.  LKML has
turned into the largest, nastiest click I've ever seen, and that's really
sad, as I'm sure it scares some good people away.  Look at all the crap I
and others got for using hotmail - I finally got sick and tired of the
whining and now have to take 3x as long to read my mail - but it's not a
hotmail address anymore, so the whining stoped.  Why not spend less timing
restricting what people can read and post from, and just let people
participate?


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263792AbTDDPy1 (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 10:54:27 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263791AbTDDPxM (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 10:53:12 -0500
Received: from chaos.analogic.com ([204.178.40.224]:54400 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP id S263789AbTDDPu4 (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 10:50:56 -0500
Date: Fri, 4 Apr 2003 11:04:14 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: William Scott Lockwood III <vlad@geekizoid.com>
cc: "David S. Miller" <davem@redhat.com>,
       Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20030404072327.J5167-100000@www.geekizoid.com>
Message-ID: <Pine.LNX.4.53.0304041055290.3824@chaos>
References: <20030404072327.J5167-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 4 Apr 2003, William Scott Lockwood III wrote:

> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > >    Well it's not a yahoo users problem because yahoo users can't fix
> > > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > > >    to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call?  I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
>
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.  How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.  The best list is one that is
> inclusive.  One that tollerates other opinions and choices.  LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away.  Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?
>

Well SPAM is a very big problem and I can see that David is trying.
Sometimes he has a bad day and pisses a few off with his answers.
However, in every case in which somebody that I know of has complained,
the problems did get "mysteriously" fixed so, like they say; "Don't go
away mad. Just go away!".

Once you get flammed for a few years, you get used to it. That's why
some people send email to me rather than "the list". Sometimes I am
able to help without having to forward their problems to the list.
Sometimes I have to take a work-break and can't help, and other times
I can't help because I don't know what they are talking about. Anyway
if David wants invoke the rage of the Gods, yawn... It doesn't bother
me anymore....


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263804AbTDDQHJ (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 11:07:09 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263803AbTDDQEc (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 11:04:32 -0500
Received: from ns.virtualhost.dk ([195.184.98.160]:18907 "EHLO virtualhost.dk")
	by vger.kernel.org with ESMTP id S263795AbTDDP7v (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 10:59:51 -0500
Date: Fri, 4 Apr 2003 18:10:48 +0200
From: Jens Axboe <axboe@suse.de>
To: William Scott Lockwood III <vlad@geekizoid.com>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
       "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030404161048.GD786@suse.de>
References: <Pine.LNX.4.53.0304040752500.2804@chaos> <20030404072327.J5167-100000@www.geekizoid.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030404072327.J5167-100000@www.geekizoid.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 04 2003, William Scott Lockwood III wrote:
> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > >    Well it's not a yahoo users problem because yahoo users can't fix
> > > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > > >    to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call?  I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
> 
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.  How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.  The best list is one that is
> inclusive.  One that tollerates other opinions and choices.  LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away.  Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?

Oh please go away. Would you rather see lkml be as ridden with spam as
other lists? You have the right to use a commercial product, and you may
also exercise your right to choose a _bad_ one.

Besides, crap like the above doesn't carry much weight. Especially not
from someone who rarely contributes anything but noise on the list. No
time for whiners, to the kill file you go.

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263786AbTDDQaB (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 11:30:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263790AbTDDQ3s (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 11:29:48 -0500
Received: from carisma.slowglass.com ([195.224.96.167]:51469 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S263786AbTDDPww (for <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Apr 2003 10:52:52 -0500
Date: Fri, 4 Apr 2003 17:04:16 +0100
From: Christoph Hellwig <hch@infradead.org>
To: William Scott Lockwood III <vlad@geekizoid.com>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
       "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030404170416.A26649@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	William Scott Lockwood III <vlad@geekizoid.com>,
	"Richard B. Johnson" <root@chaos.analogic.com>,
	"David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.53.0304040752500.2804@chaos> <20030404072327.J5167-100000@www.geekizoid.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030404072327.J5167-100000@www.geekizoid.com>; from vlad@geekizoid.com on Fri, Apr 04, 2003 at 07:28:12AM -0800
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.

LKML is DaveM's list.  If the choice he and his co-postmaster make don't
suit yours or others need setup your own linux kernel list.

> How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.

Who said anything about commercial products?  lkml refuses _broken_
mails, it doesn't check what MUA you used.

> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?

Please red the mail RFC and the nettiquette and come back once you've
done that.  Your current whining wastes our time.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261305AbTDDU0K (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 15:26:10 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261308AbTDDU0K (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 15:26:10 -0500
Received: from mail.zmailer.org ([62.240.94.4]:46822 "EHLO mail.zmailer.org")
	by vger.kernel.org with ESMTP id S261305AbTDDU0F (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 15:26:05 -0500
Date: Fri, 4 Apr 2003 23:37:31 +0300
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: William Scott Lockwood III <vlad@geekizoid.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030404203731.GU29167@mea-ext.zmailer.org>
References: <Pine.LNX.4.53.0304040752500.2804@chaos> <20030404072327.J5167-100000@www.geekizoid.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030404072327.J5167-100000@www.geekizoid.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
...
> The best list is one that is inclusive.  One that tollerates other opinions
> and choices.  LKML has turned into the largest, nastiest click I've ever
> seen, and that's really sad, as I'm sure it scares some good people away.

Are you speaking about PEOPLE who react on emails by flaming, or
something of list filtering "technology" ?

>  Look at all the crap I and others got for using hotmail - I finally
> got sick and tired of the whining and now have to take 3x as long to 
> read my mail - but it's not a hotmail address anymore, so the whining
> stoped.

About people, then..    There I can't help, unfortunately.

We have lots of people subscribing on Hotmail addresses, and only 
complaint I can voice is that those people will at times let their
mailbox quotas overflow, which leads to bounces, and then subscription
revocation...  (Hard controlled quotas are not unique to Hotmail, nor
people who let them overflow...)


> Why not spend less timing restricting what people can read and post
> from, and just let people participate?

There is this small thing called spam...

We have various filters (see my other posting), but obviously they
are not infallible, a few spams do leak thru, and earn new filter
rules (if I can think up something suitably specific, while generic..)

A somewhat better anti-spam filter method, than what we use presently
is to use strictly CLOSED list -- e.g. must be a member to post.
I have seen what kind of pains closed lists are, I even moderate
couple small ones.

However we are deliberately running "open for posting, subject to
filters" policy, which lets questions and reports to come from
non-subscribers.


/Matti Aarnio

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261362AbTDDV6s (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 16:58:48 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261366AbTDDV6s (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 16:58:48 -0500
Received: from adsl-67-120-62-187.dsl.lsan03.pacbell.net ([67.120.62.187]:8714
	"EHLO exchange.macrolink.com") by vger.kernel.org with ESMTP
	id S261362AbTDDV6r (for <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Apr 2003 16:58:47 -0500
Message-ID: <11E89240C407D311958800A0C9ACF7D1A33E26@EXCHANGE>
From: Ed Vance <EdV@macrolink.com>
To: "'Matti Aarnio'" <matti.aarnio@zmailer.org>
Cc: William Scott Lockwood III <vlad@geekizoid.com>,
       linux-kernel@vger.kernel.org
Subject: RE: your mail
Date: Fri, 4 Apr 2003 14:10:16 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> [snip]
> A somewhat better anti-spam filter method, than what we use presently
> is to use strictly CLOSED list -- e.g. must be a member to post.
> I have seen what kind of pains closed lists are, I even moderate
> couple small ones.
> 
> However we are deliberately running "open for posting, subject to
> filters" policy, which lets questions and reports to come from
> non-subscribers.
> 

Perhaps there is a middle ground. Leave the list open, but require a
confirmation reply prior to passing along posts from addresses that:

1. are not members of the list, AND
2. have not previously done a proper confirmation reply.

The unconfirmed posts would time out and disappear after a decent interval,
to prevent constipation.

So, anybody could still post, the members would not be inconvenienced, and
non-members would be inconvenienced only on their first post from each
address they post from. This would preserve the "real time" nature of the
list, while gaining the assurance that all who post are life-forms, even if
they live in front of a keyboard and have no real life.  ;-)

Of course, this would require storage for the list of confirmed addresses
and pending unconfirmed posts, and the bandwidth and other overhead of the
infrequent confirmation messages.

Just a thought. 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261452AbTDDXHn (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 18:07:43 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261449AbTDDXHn (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 18:07:43 -0500
Received: from lrsehosting.com ([198.78.66.31]:31754 "EHLO www.geekizoid.com")
	by vger.kernel.org with ESMTP id S261452AbTDDXHm (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 18:07:42 -0500
Date: Fri, 4 Apr 2003 15:19:07 -0800 (PST)
From: William Scott Lockwood III <vlad@geekizoid.com>
To: Ed Vance <EdV@macrolink.com>
cc: "'Matti Aarnio'" <matti.aarnio@zmailer.org>,
       <linux-kernel@vger.kernel.org>
Subject: RE: your mail
In-Reply-To: <11E89240C407D311958800A0C9ACF7D1A33E26@EXCHANGE>
Message-ID: <20030404151844.M64445-100000@www.geekizoid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

That is the best suggestion I've yet seen.  It's an excellent idea!

On Fri, 4 Apr 2003, Ed Vance wrote:

> On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> > [snip]
> > A somewhat better anti-spam filter method, than what we use presently
> > is to use strictly CLOSED list -- e.g. must be a member to post.
> > I have seen what kind of pains closed lists are, I even moderate
> > couple small ones.
> >
> > However we are deliberately running "open for posting, subject to
> > filters" policy, which lets questions and reports to come from
> > non-subscribers.
> >
>
> Perhaps there is a middle ground. Leave the list open, but require a
> confirmation reply prior to passing along posts from addresses that:
>
> 1. are not members of the list, AND
> 2. have not previously done a proper confirmation reply.
>
> The unconfirmed posts would time out and disappear after a decent interval,
> to prevent constipation.
>
> So, anybody could still post, the members would not be inconvenienced, and
> non-members would be inconvenienced only on their first post from each
> address they post from. This would preserve the "real time" nature of the
> list, while gaining the assurance that all who post are life-forms, even if
> they live in front of a keyboard and have no real life.  ;-)
>
> Of course, this would require storage for the list of confirmed addresses
> and pending unconfirmed posts, and the bandwidth and other overhead of the
> infrequent confirmation messages.
>
> Just a thought.
>
> Cheers,
> Ed
>
> ----------------------------------------------------------------
> Ed Vance              edv (at) macrolink (dot) com
> Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
> ----------------------------------------------------------------
>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261412AbTDDXKj (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 18:10:39 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261449AbTDDXKj (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 18:10:39 -0500
Received: from mail.ocs.com.au ([203.34.97.2]:37382 "HELO mail.ocs.com.au")
	by vger.kernel.org with SMTP id S261412AbTDDXKi (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 18:10:38 -0500
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@ocs.com.au>
To: Ed Vance <EdV@macrolink.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-reply-to: Your message of "Fri, 04 Apr 2003 14:10:16 PST."
             <11E89240C407D311958800A0C9ACF7D1A33E26@EXCHANGE> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 05 Apr 2003 09:21:22 +1000
Message-ID: <27796.1049498482@ocs3.intra.ocs.com.au>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 4 Apr 2003 14:10:16 -0800 , 
Ed Vance <EdV@macrolink.com> wrote:
>Perhaps there is a middle ground. Leave the list open, but require a
>confirmation reply prior to passing along posts from addresses that:
>
>1. are not members of the list, AND
>2. have not previously done a proper confirmation reply.

30 seconds after doing that, the spammers will forge email that claims
to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
forge the headers.  Verification by 'From:' line on an open list is
pointless.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261598AbTDEA1W (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 19:27:22 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261605AbTDEA1W (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 19:27:22 -0500
Received: from adsl-67-120-62-187.dsl.lsan03.pacbell.net ([67.120.62.187]:42500
	"EHLO exchange.macrolink.com") by vger.kernel.org with ESMTP
	id S261598AbTDEA1U (for <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Apr 2003 19:27:20 -0500
Message-ID: <11E89240C407D311958800A0C9ACF7D1A33E27@EXCHANGE>
From: Ed Vance <EdV@macrolink.com>
To: "'Keith Owens'" <kaos@ocs.com.au>,
       "'Matti Aarnio'" <matti.aarnio@zmailer.org>
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail 
Date: Fri, 4 Apr 2003 16:38:50 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
> 
> On Fri, 4 Apr 2003 14:10:16 -0800 , 
> Ed Vance <EdV@macrolink.com> wrote:
> >Perhaps there is a middle ground. Leave the list open, but require a
> >confirmation reply prior to passing along posts from addresses that:
> >
> >1. are not members of the list, AND
> >2. have not previously done a proper confirmation reply.
> 
> 30 seconds after doing that, the spammers will forge email that claims
> to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
> forge the headers.  Verification by 'From:' line on an open list is
> pointless.
> 

Keith,

No single method is perfect. Your point is well taken. 

The goal was to greatly reduce, in one swell foop, the volume of spam that
the filters (and postmaster) must interactively deal with. I thought that
perhaps this method could replace one of more of the troublesome filtering
techniques to achieve the same net spam reduction without evoking as much
whining.

imperfect != pointless

Matti, 
Roughly what percentage of the spam actually hitting vger today (and
bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent? 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261798AbTDEEj7 (for <rfc822;willy@w.ods.org>); Fri, 4 Apr 2003 23:39:59 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261800AbTDEEj7 (for <rfc822;linux-kernel-outgoing>); Fri, 4 Apr 2003 23:39:59 -0500
Received: from mail.ocs.com.au ([203.34.97.2]:9735 "HELO mail.ocs.com.au")
	by vger.kernel.org with SMTP id S261798AbTDEEj5 (for <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 4 Apr 2003 23:39:57 -0500
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@ocs.com.au>
To: Ed Vance <EdV@macrolink.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail 
In-reply-to: Your message of "Fri, 04 Apr 2003 16:38:50 PST."
             <11E89240C407D311958800A0C9ACF7D1A33E27@EXCHANGE> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 05 Apr 2003 14:51:16 +1000
Message-ID: <30498.1049518276@ocs3.intra.ocs.com.au>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 4 Apr 2003 16:38:50 -0800 , 
Ed Vance <EdV@macrolink.com> wrote:
>On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
>> 
>> On Fri, 4 Apr 2003 14:10:16 -0800 , 
>> Ed Vance <EdV@macrolink.com> wrote:
>> >Perhaps there is a middle ground. Leave the list open, but require a
>> >confirmation reply prior to passing along posts from addresses that:
>> >
>> >1. are not members of the list, AND
>> >2. have not previously done a proper confirmation reply.
>> 
>> 30 seconds after doing that, the spammers will forge email that claims
>> to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
>> forge the headers.  Verification by 'From:' line on an open list is
>> pointless.
>> 
>The goal was to greatly reduce, in one swell foop, the volume of spam that
>the filters (and postmaster) must interactively deal with. I thought that
>perhaps this method could replace one of more of the troublesome filtering
>techniques to achieve the same net spam reduction without evoking as much
>whining.

Paraphrase: Replace filtering code that catches spam with filtering
code based on checking header content that can be trivially forged by
spammers.

>Matti, 
>Roughly what percentage of the spam actually hitting vger today (and
>bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent? 

Current figures are irrelevant, spammers react to spam filters and they
react very quickly[*].  If you replace "reject HTML bodies" with "allow
HTML based on known From: lines" then the spammers will send HTML
bodies with forged headers, because they know it will get through.
That will require the original HTML filters to be reintroduced, the end
result is you added an extra step for new posters without reducing the
spam or users whining "my mail does not get through".

[*] About 24 hours after slashdot carried a story on Baysian spam
    filters, I started receiving HTML spam that contained comments that
    were designed to fool the Baysian filters, like this.

    FREE 1 MONTH SUPP<!--kernel-->Y WITH THIS

    The comment has no effect on the spam display but the use of
    non-spam words skews the Baysian rules on whether the content is
    spam or not.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263772AbTDYTkc (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 25 Apr 2003 15:40:32 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263854AbTDYTkc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 25 Apr 2003 15:40:32 -0400
Received: from electric-eye.fr.zoreil.com ([213.41.134.224]:45067 "EHLO
	fr.zoreil.com") by vger.kernel.org with ESMTP id S263772AbTDYTkc
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Apr 2003 15:40:32 -0400
Date: Fri, 25 Apr 2003 21:43:51 +0200
From: Francois Romieu <romieu@fr.zoreil.com>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030425214351.A5353@electric-eye.fr.zoreil.com>
References: <7A25937D23A1E64C8E93CB4A50509C2A0179B590@stca204a.bus.sc.rolm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <7A25937D23A1E64C8E93CB4A50509C2A0179B590@stca204a.bus.sc.rolm.com>; from Jack.Bloch@icn.siemens.com on Fri, Apr 25, 2003 at 10:35:53AM -0700
X-Organisation: Marie's fan club - III
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Bloch, Jack <Jack.Bloch@icn.siemens.com> :
> Is there example driver source code available for a MUSYCC CN8478 device?
> Please CC me directly on any answers. 

http://ww.google.com/search?q=musycc.c+bsd&ie=ISO-8859-1&hl=fr&lr=

Example source code for a complete reset of a PEB20534 device operating in
last descriptor address control mode will be welcome too.

Regards

--
Ueimor

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262578AbTD3Xv0 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 30 Apr 2003 19:51:26 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262584AbTD3Xv0
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 30 Apr 2003 19:51:26 -0400
Received: from granite.he.net ([216.218.226.66]:15877 "EHLO granite.he.net")
	by vger.kernel.org with ESMTP id S262578AbTD3XvY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 30 Apr 2003 19:51:24 -0400
Date: Wed, 30 Apr 2003 17:05:47 -0700
From: Greg KH <greg@kroah.com>
To: Mauricio Oliveira Carneiro <carneiro@tecgraf.puc-rio.br>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030501000547.GA26186@kroah.com>
References: <oprogo4fzred667r@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <oprogo4fzred667r@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 30, 2003 at 06:39:41PM -0300, Mauricio Oliveira Carneiro wrote:
> But I can't see it mounted anywhere in my system, nor can I mount it by 
> hand since I don't know the device filename (/dev/?) .

Have you read the Linux USB Guide at http://www.linux-usb.org/ ?

If you still have questions/problems after reading that, try asking this
on the linux-usb-users mailing list.  The people there can help you out.

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261232AbTEHI5m (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 8 May 2003 04:57:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261234AbTEHI5m
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 8 May 2003 04:57:42 -0400
Received: from hirsch.in-berlin.de ([192.109.42.6]:43161 "EHLO
	hirsch.in-berlin.de") by vger.kernel.org with ESMTP id S261232AbTEHI5l
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 8 May 2003 04:57:41 -0400
X-Envelope-From: kraxel@bytesex.org
Date: Thu, 8 May 2003 11:06:38 +0200
From: Gerd Knorr <kraxel@bytesex.org>
To: ark925@netscape.net
Cc: Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20030508090638.GE17300@bytesex.org>
References: <053C05D4.4D025D2E.0005F166@netscape.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <053C05D4.4D025D2E.0005F166@netscape.net>
User-Agent: Mutt/1.5.3i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Actually it does in some cases. I know of two devices that have analog
> tuners on an smbus-like interface (OV511 USB TV and W9967CF USB TV). The
> tuner can be controlled using a pair of i2c_smbus_write_byte_data()
> calls.

Hmm, maybe we should rename the SMBUS class to SENSORS or MAINBOARD or
something like that?  I assumed you smbus interfaces are used for
mainboard sensors only ...

> Would a patch that adds smbus algorithm support to tuner.c be
> acceptable?

Yes.  Certainly makes more sense than duplicating the whole rest of
tuner.c just for a smbus-aware tuner driver ;)

  Gerd

-- 
sigfault

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264396AbTEPJrd (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 16 May 2003 05:47:33 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264397AbTEPJrc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 16 May 2003 05:47:32 -0400
Received: from dns.toxicfilms.tv ([150.254.37.24]:5765 "EHLO dns.toxicfilms.tv")
	by vger.kernel.org with ESMTP id S264396AbTEPJrc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 16 May 2003 05:47:32 -0400
Date: Fri, 16 May 2003 12:00:18 +0200 (CEST)
From: Maciej Soltysiak <solt@dns.toxicfilms.tv>
To: dirf <dirf@ciget.granma.inf.cu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <022301c31a48$7b8272e0$848e9ea9@vh>
Message-ID: <Pine.LNX.4.51.0305161142340.1038@dns.toxicfilms.tv>
References: <022301c31a48$7b8272e0$848e9ea9@vh>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> - Where I can find a list of RFCs?
http://www.ietf.org/rfc

There is a RFC Index link

> - Where I can find a cdfs format ( cd file system format)?
You mean kernel drivers or the specification?
The kernel drivers are in the stock kernel.

Regards,
Maciej


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S275643AbTHODbu (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 14 Aug 2003 23:31:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S275668AbTHODbu
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 14 Aug 2003 23:31:50 -0400
Received: from blackbird.intercode.com.au ([203.32.101.10]:12301 "EHLO
	blackbird.intercode.com.au") by vger.kernel.org with ESMTP
	id S275643AbTHODbt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 14 Aug 2003 23:31:49 -0400
Date: Fri, 15 Aug 2003 13:31:32 +1000 (EST)
From: James Morris <jmorris@intercode.com.au>
To: kartikey bhatt <kartik_me@hotmail.com>
cc: davem@redhat.com, <linux-kernel@vger.kernel.org>, <alan@redhat.com>
Subject: Re: your mail
In-Reply-To: <LAW11-F7Fogr0M4ixCQ0003d56c@hotmail.com>
Message-ID: <Mutt.LNX.4.44.0308151330280.26882-100000@excalibur.intercode.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 15 Aug 2003, kartikey bhatt wrote:

> Hi James.
> A little bit work for you.
> Somebody on mailing list commented that you should *really* go for better
> algorithm like CAST6 (rfc2612) to be included in kernel.
> This time I'm sending you cast6.c (cast6 cipher algorithm) implementation.
> But this time it's a patch.

Cool.  Unfortunately the patch is corrupted, please try sending as an 
attachment or via a different mail system.


- James
-- 
James Morris
<jmorris@intercode.com.au>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S275052AbTHRUn2 (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 18 Aug 2003 16:43:28 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S275055AbTHRUn2
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 18 Aug 2003 16:43:28 -0400
Received: from mail.kroah.org ([65.200.24.183]:5761 "EHLO perch.kroah.org")
	by vger.kernel.org with ESMTP id S275052AbTHRUnS (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 Aug 2003 16:43:18 -0400
Date: Mon, 18 Aug 2003 13:42:18 -0700
From: Greg KH <greg@kroah.com>
To: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: jw schultz <jw@pegasys.ws>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030818204218.GA3220@kroah.com>
References: <E19odOM-000NwL-00.arvidjaar-mail-ru@f22.mail.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E19odOM-000NwL-00.arvidjaar-mail-ru@f22.mail.ru>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> 
> just to show what I expected from sysfs - here is entry from Solaris
> /devices:
> 
> brw-r-----   1 root     sys       32,240 Jan 24  2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a
> 
> this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0
> connected to bus 1 of controller in slot 5 of PCI bus identified
> by 16. Now you can use whatever policy you like to give human
> meaningful name to this entry. And if you have USB it will continue
> further giving you exact topology starting from the root of your
> device tree.
> 
> and this path does not contain single logical id so it is not subject
> to change if I add the same controller somewhere else.
> 
> hopefully it clarifies what I mean ...

Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
of my machines and tell me if it has all the info you are looking for:

$ tree /sys/bus/scsi/
/sys/bus/scsi/
|-- devices
|   `-- 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
`-- drivers
    `-- sd
        `-- 0:0:0:0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0

$ tree /sys/block/sda/
/sys/block/sda/
|-- dev
|-- device -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
|-- queue
|   |-- iosched
|   |   |-- antic_expire
|   |   |-- read_batch_expire
|   |   |-- read_expire
|   |   |-- write_batch_expire
|   |   `-- write_expire
|   `-- nr_requests
|-- range
|-- sda1
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda2
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda3
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda4
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- size
`-- stat


Now, from that you can see exactly where my scsi device is in the pci
tree, and you can see in the block directory, what block device is
assigned to what physical device in the device tree.  Then there are 4
partitions on this disk, all what those specific paramaters.

So, when sda shows up, udev can determine that it lives on a specific
scsi device, located in a specific place in the pci space, and that it
has some number of partitions, all of specific sizes, wich specific
major/minor numbers.  It can then create all of the /dev links based on
this.

Please, take a few minutes looking at the existing sysfs tree on Linux.
If you then have any specific questions, I would be glad to answer
them.

Hope this helps,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261904AbTHYOah (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Aug 2003 10:30:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261909AbTHYOah
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Aug 2003 10:30:37 -0400
Received: from www.13thfloor.at ([212.16.59.250]:712 "EHLO www.13thfloor.at")
	by vger.kernel.org with ESMTP id S261904AbTHYOag (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Aug 2003 10:30:36 -0400
Date: Mon, 25 Aug 2003 16:30:46 +0200
From: Herbert =?iso-8859-1?Q?P=F6tzl?= <herbert@13thfloor.at>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20030825143046.GB10657@www.13thfloor.at>
Reply-To: herbert@13thfloor.at
Mail-Followup-To: Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.55L.0308251050550.11102@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55L.0308251050550.11102@freak.distro.conectiva>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> 
> >
> >
> > Matthias Andree wrote:
> >
> > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > >
> > >
> > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > >>
> > >
> > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > >
> >
> > Maybe some of Andrea's VM stuff?
> 
> Definately. Thats the first thing I'm going to do after looking through
> "2.4.23-pre-patches" folder.

any chance for the Bind Mount Extensions? 8-)

best,
Herbert

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262010AbTHYQtw (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Aug 2003 12:49:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261960AbTHYQtw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Aug 2003 12:49:52 -0400
Received: from perninha.conectiva.com.br ([200.250.58.156]:34028 "EHLO
	perninha.conectiva.com.br") by vger.kernel.org with ESMTP
	id S262010AbTHYQtv convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Aug 2003 12:49:51 -0400
Date: Mon, 25 Aug 2003 13:45:25 -0300 (BRT)
From: Marcelo Tosatti <marcelo@conectiva.com.br>
X-X-Sender: marcelo@freak.distro.conectiva
To: =?ISO-8859-1?Q?Herbert_P=F6tzl?= <herbert@13thfloor.at>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <Pine.LNX.4.55L.0308251222500.12395@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 25 Aug 2003, Herbert Pötzl wrote:

> On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> >
> > >
> > >
> > > Matthias Andree wrote:
> > >
> > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > >
> > > >
> > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > >>
> > > >
> > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > >
> > >
> > > Maybe some of Andrea's VM stuff?
> >
> > Definately. Thats the first thing I'm going to do after looking
through
> > "2.4.23-pre-patches" folder.
>
> any chance for the Bind Mount Extensions? 8-)

I haven't found time to at the patch yet but will do so soon.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262062AbTHYRAW (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Aug 2003 13:00:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262008AbTHYRAV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Aug 2003 13:00:21 -0400
Received: from www.13thfloor.at ([212.16.59.250]:714 "EHLO www.13thfloor.at")
	by vger.kernel.org with ESMTP id S262062AbTHYQ7h (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Aug 2003 12:59:37 -0400
Date: Mon, 25 Aug 2003 18:59:50 +0200
From: Herbert =?iso-8859-1?Q?P=F6tzl?= <herbert@13thfloor.at>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20030825165949.GA23306@www.13thfloor.at>
Reply-To: herbert@13thfloor.at
Mail-Followup-To: Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.55L.0308251222500.12395@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.LNX.4.55L.0308251222500.12395@freak.distro.conectiva>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 25, 2003 at 01:45:25PM -0300, Marcelo Tosatti wrote:
> On Mon, 25 Aug 2003, Herbert Pötzl wrote:
> 
> > On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> > >
> > > >
> > > >
> > > > Matthias Andree wrote:
> > > >
> > > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > > >
> > > > >
> > > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > > >>
> > > > >
> > > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > > >
> > > >
> > > > Maybe some of Andrea's VM stuff?
> > >
> > > Definately. Thats the first thing I'm going to do after looking
> through
> > > "2.4.23-pre-patches" folder.
> >
> > any chance for the Bind Mount Extensions? 8-)
> 
> I haven't found time to at the patch yet but will do so soon.

fine, no problem, let me know if you need something
(like rediff, resend, explanation, etc ...)

best,
Herbert


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263579AbTH0QCr (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Aug 2003 12:02:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263580AbTH0QCq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Aug 2003 12:02:46 -0400
Received: from holomorphy.com ([66.224.33.161]:34744 "EHLO holomorphy")
	by vger.kernel.org with ESMTP id S263579AbTH0QBe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Aug 2003 12:01:34 -0400
Date: Wed, 27 Aug 2003 09:02:33 -0700
From: William Lee Irwin III <wli@holomorphy.com>
To: warudkar@vsnl.net
Cc: kernel@kolivas.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
Subject: Re: your mail
Message-ID: <20030827160233.GE4306@holomorphy.com>
Mail-Followup-To: William Lee Irwin III <wli@holomorphy.com>,
	warudkar@vsnl.net, kernel@kolivas.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@osdl.org>
References: <200308280225.h7S2PNa26057@webmail2.vsnl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200308280225.h7S2PNa26057@webmail2.vsnl.net>
Organization: The Domain of Holomorphy
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 27, 2003 at 09:25:23PM -0500, warudkar@vsnl.net wrote:
> Con - With swappiness set to 100, the apps do start up in 3 minutes and kswapd doesn't hog the CPU. But X is still unusable till all of them have started up.
> Wli - Sorry, vmstat segfaults on 2.6!

This is a bug in older versions of vmstat. Upgrade vmstat.


-- wli

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261438AbTI3Nbl (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 09:31:41 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261459AbTI3Nbl
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 09:31:41 -0400
Received: from pix-525-pool.redhat.com ([66.187.233.200]:56119 "EHLO
	lacrosse.corp.redhat.com") by vger.kernel.org with ESMTP
	id S261438AbTI3Nbj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 09:31:39 -0400
Date: Tue, 30 Sep 2003 14:31:13 +0100
From: Dave Jones <davej@redhat.com>
To: John Bradford <john@grabjohn.com>
Cc: Jamie Lokier <jamie@shareable.org>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930133113.GC23333@redhat.com>
Mail-Followup-To: Dave Jones <davej@redhat.com>,
	John Bradford <john@grabjohn.com>,
	Jamie Lokier <jamie@shareable.org>, akpm@osdl.org,
	torvalds@osdl.org, linux-kernel@vger.kernel.org
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk>
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
 
 > Of course a kernel compiled strictly for 386s may seem to boot on an
 > Athlon but not work properly.  So what?  Just don't run the 'wrong'
 > kernel.

Wrong answer. How do you intend to install Linux when a distro boot
kernel is compiled for lowest-common-denominator (386), and is the
'wrong' kernel for an Athlon ?

We hashed this argument out a week or so ago, it seems the message
didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

clearer ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261506AbTI3OGt (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 10:06:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261507AbTI3OGt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 10:06:49 -0400
Received: from mail.jlokier.co.uk ([81.29.64.88]:646 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261506AbTI3OGr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 10:06:47 -0400
Date: Tue, 30 Sep 2003 15:06:27 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Dave Jones <davej@redhat.com>, John Bradford <john@grabjohn.com>,
       akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930140627.GB28876@mail.shareable.org>
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930133113.GC23333@redhat.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Dave Jones wrote:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
>  > Of course a kernel compiled strictly for 386s may seem to boot on an
>  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
>  > kernel.
> 
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?

I'm not sure what the fuss is; a strict 386 kernel runs just fine
without any problems on an Athlon.  But anyway...

Dave, you are conflating "kernel compiled strictly for 386s" with
"compiled for lowest-common-denominator".

They are totally different configurations.  Isn't that why we have
"generic" now?

The latter is for distro boots.  The former is for that
386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
everything it can, and no errata thank you.

I've not heard of anyone actually wanting a strict 386 kernel lately,
but strict 486 is not so unusual.

Just as some people want a P4 optimised kernel, and some people want a
K7 optimised kernel, so some people want a 386 or 486 or Pentium
optimised kernel.  Lowest-common-denominator means it runs on
everything, and isn't really anything to do with 386 any more - that's
not really the lowest-common-denominator, by virtue of the obvious
fact that pure 386 code isn't reliable on all other CPUs.

> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

I agree.  It shouln't be possible to boot on the wrong hardware: it
should refuse.

There is precedent: X86_GOOD_APIC && X86_LOCAL_APIC: when booted on a
non-MMX P5, it refuses to boot, because it does not contain the errata
workaround.

Unfortunately the kernel has opposite precedents too.

By selecting a PII kernel, it is possible to configure out the code
for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
_can_ possibly boot on kernels where the errata are needed, and nary a
printk is emitted for it.  Nasty bugs they are, too.

More generally than the CPU, you can also configure out BLK_DEV_RZ1000
which is another crucial workaround that needs to go in any
lowest-common-denominator kernel.  Basically, if you're building a
distro boot kernel, you must turn on all known workarounds.  That's
certainly lowest-common-denominator, but it's a far cry from the
configuration that a 386-as-firewall user wants.

> clearer?

If the kernel had a consistent policy so far, it would be more clear,
but it doesn't.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261512AbTI3OKV (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 10:10:21 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261514AbTI3OKV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 10:10:21 -0400
Received: from 81-2-122-30.bradfords.org.uk ([81.2.122.30]:46464 "EHLO
	81-2-122-30.bradfords.org.uk") by vger.kernel.org with ESMTP
	id S261512AbTI3OKM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 10:10:12 -0400
Date: Tue, 30 Sep 2003 15:10:14 +0100
From: John Bradford <john@grabjohn.com>
Message-Id: <200309301410.h8UEAEgJ000652@81-2-122-30.bradfords.org.uk>
To: Dave Jones <davej@redhat.com>
Cc: Jamie Lokier <jamie@shareable.org>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <20030930133113.GC23333@redhat.com>
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk>
 <20030930133113.GC23333@redhat.com>
Subject: Re: your mail
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Quote from Dave Jones <davej@redhat.com>:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
>  
>  > Of course a kernel compiled strictly for 386s may seem to boot on an
>  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
>  > kernel.
> 
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?

I don't.  I *never* suggested doing that.  I clearly said a kernel
compiled *strictly* for 386s.  I.E. Without support for other
processors.

> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

It seems the message didn't get across to you.

Have you actually looked at Adrian's patch?

*Forget* that 386=lowest-common-denominator.  This
'386=lowest-common-denominator' theme is out of date, and we should be
moving away from it - oh, hang on, that's exactly what Adrian's patch
allows us to do.

A distribution installation kernel needs to boot all supported
hardware - of course it does.  So what?  Just select support for all
the processors in the configurator.  No, don't just select 386,
because 386 doesn't mean 386 and above anymore with Adrian's patch, it
means support 386 and don't bloat the kernel with workarounds for
other processors.  Select *all* processors.  Now you have a nice,
(bloated), kernel that boots on the same hardware that you old '386'
one did.  Fine for installation on diverse hardware.  Rubbish for
performance.

Unless, of course, you object to the possibility that somebody might
go out of their way to compile a 386 specific kernel from source
themselves, then run it on an Athlon.  By chance it will probably
appear to work OK, but won't have the workaround enabled.  So what?
Only somebody who knows exactly what they were doing is likely to do
that - how could it happen by accident?  If you really must, put a
warning in to say, 'This kernel doesn't support your processor', but
doing that just adds more bloat.  OK, so the bloat will be freed after
boot, but it's still bloat on the boot device, which matters in some
embedded systems.

> clearer ?

It's clear that you didn't read my original post, yes.

John.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261522AbTI3Oug (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 10:50:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261538AbTI3Oug
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 10:50:36 -0400
Received: from pix-525-pool.redhat.com ([66.187.233.200]:34265 "EHLO
	lacrosse.corp.redhat.com") by vger.kernel.org with ESMTP
	id S261522AbTI3Ouc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 10:50:32 -0400
Date: Tue, 30 Sep 2003 15:50:08 +0100
From: Dave Jones <davej@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: John Bradford <john@grabjohn.com>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930145007.GB12812@redhat.com>
Mail-Followup-To: Dave Jones <davej@redhat.com>,
	Jamie Lokier <jamie@shareable.org>,
	John Bradford <john@grabjohn.com>, akpm@osdl.org, torvalds@osdl.org,
	linux-kernel@vger.kernel.org
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com> <20030930140627.GB28876@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930140627.GB28876@mail.shareable.org>
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 30, 2003 at 03:06:27PM +0100, Jamie Lokier wrote:
 > Dave Jones wrote:
 > > On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
 > >  > Of course a kernel compiled strictly for 386s may seem to boot on an
 > >  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
 > >  > kernel.
 > > Wrong answer. How do you intend to install Linux when a distro boot
 > > kernel is compiled for lowest-common-denominator (386), and is the
 > > 'wrong' kernel for an Athlon ?
 > I'm not sure what the fuss is; a strict 386 kernel runs just fine
 > without any problems on an Athlon.  But anyway...

Unless it got configured away as proposed in your earlier patch.

 > Dave, you are conflating "kernel compiled strictly for 386s" with
 > "compiled for lowest-common-denominator".
 > 
 > They are totally different configurations.  Isn't that why we have
 > "generic" now?

CONFIG_GENERIC could be extended to offer other options yes,
but right now what it does doesn't really match the name IMO.
Right now its closer to a CONFIG_MAX_CACHELINE_SIZE

 > The latter is for distro boots.  The former is for that
 > 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
 > everything it can, and no errata thank you.

Again, 'trimming' away a few hundred bytes of errata workarounds
is ridiculous when we have bigger fish to fry where we can save
KBs of .text size, and MB's of runtime memory.

 > I've not heard of anyone actually wanting a strict 386 kernel lately,
 > but strict 486 is not so unusual.

ISTR that current gcc's emit 486 instructions anyway, so its possible
that with a modern toolchain, you can't *build* a 386 kernel.
I'm not sure if that got fixed or not, I don't track gcc lists any more.

 > Just as some people want a P4 optimised kernel, and some people want a
 > K7 optimised kernel, so some people want a 386 or 486 or Pentium
 > optimised kernel.  Lowest-common-denominator means it runs on
 > everything, and isn't really anything to do with 386 any more - that's
 > not really the lowest-common-denominator, by virtue of the obvious
 > fact that pure 386 code isn't reliable on all other CPUs.

Elaborate? "pure 386 code" (whatever that means in your definition)
should run perfectly reliable on every CPU we care about.

 > > We hashed this argument out a week or so ago, it seems the message
 > > didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
 > > THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
 > I agree.  It shouln't be possible to boot on the wrong hardware: it
 > should refuse.

So first you argue for compiling out a few hundred bytes of errata
workaround, now you want to instead compile in checks & printk's
(which probably add up to not far off the same amount of space).

 > By selecting a PII kernel, it is possible to configure out the code
 > for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
 > _can_ possibly boot on kernels where the errata are needed, and nary a
 > printk is emitted for it.  Nasty bugs they are, too.

Indeed. That's arguably a bug that occured when someone split the
original CONFIG_M686 into _M686 & MPENTIUMII.

 > More generally than the CPU, you can also configure out BLK_DEV_RZ1000
 > which is another crucial workaround that needs to go in any
 > lowest-common-denominator kernel.

I wouldn't look at the history of drivers/ide/ as a shining example of
good design 8-)

 > Basically, if you're building a
 > distro boot kernel, you must turn on all known workarounds.  That's
 > certainly lowest-common-denominator, but it's a far cry from the
 > configuration that a 386-as-firewall user wants.

Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
and arch/i386/Makefile into guacamole.  After spending so much time
getting that crap into something maintainable, it seemed a huge step
backwards to litter it with dozens of ifdefs and duplication.
There has to be a cleaner way of pleasing everyone.

 > > clearer?
 > If the kernel had a consistent policy so far, it would be more clear,
 > but it doesn't.

Agreed, there are some questionable parts.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261552AbTI3O7T (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 10:59:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261551AbTI3O7T
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 10:59:19 -0400
Received: from mail.jlokier.co.uk ([81.29.64.88]:3974 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261552AbTI3O7N (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 10:59:13 -0400
Date: Tue, 30 Sep 2003 15:58:54 +0100
From: Jamie Lokier <jamie@shareable.org>
To: John Bradford <john@grabjohn.com>
Cc: Dave Jones <davej@redhat.com>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930145854.GD28876@mail.shareable.org>
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com> <200309301410.h8UEAEgJ000652@81-2-122-30.bradfords.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309301410.h8UEAEgJ000652@81-2-122-30.bradfords.org.uk>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

John Bradford wrote:
> Unless, of course, you object to the possibility that somebody might
> go out of their way to compile a 386 specific kernel from source
> themselves, then run it on an Athlon.  By chance it will probably
> appear to work OK, but won't have the workaround enabled.  So what?

Actually the 386 kernel will work just fine on the AMD...  The
workaround is only needed, in the kernel, to protect against the
kernel's own use of non-386 features...

Userspace is a different matter, but userspace has a lot of
model-specific things to worry about beyond this one instruction on
AMD.  In practice: bswap, cmov, cmpxchg, mmx, sse, sse2, so knowing
whether to use prefetch or not is just one more variable for userspace
- and one which any portable app or library will have to know about in
any case.

(Aside: It is quite an anomaly that those cumbersome floating point
instructions are emulated on the older CPUs, yet all the other
instructions aren't emulated.  Emulation is very slow, and forcing
userspace to just use different code instead is good, but that's just
as valid for floating point as it is for MMX, cmpxchg etc.)

> Only somebody who knows exactly what they were doing is likely to do
> that - how could it happen by accident?  If you really must, put a
> warning in to say, 'This kernel doesn't support your processor', but
> doing that just adds more bloat.  OK, so the bloat will be freed after
> boot, but it's still bloat on the boot device, which matters in some
> embedded systems.

To be fair, the kernel really ought to just say that and halt.  That
is a fine compromise.  It won't make embedded systems folks completely
happy, because if you've only got 2MB of NVRAM for your whole kernel
_and_ filesystem including user data (think PDA or cellphone), then a
hundred bytes here or there is actually worth trimming.

But then, those sort of embedded folks should just figure out
compressed software-suspend, and then they can ditch __init data from
the NVRAM image completely.  It's much better to lose all of __init
than just a few bytes here or there, isn't it?

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261569AbTI3PLs (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 11:11:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261580AbTI3PLs
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 11:11:48 -0400
Received: from pix-525-pool.redhat.com ([66.187.233.200]:5896 "EHLO
	lacrosse.corp.redhat.com") by vger.kernel.org with ESMTP
	id S261569AbTI3PLq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 11:11:46 -0400
Date: Tue, 30 Sep 2003 16:11:23 +0100
From: Dave Jones <davej@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: John Bradford <john@grabjohn.com>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930151123.GA16397@redhat.com>
Mail-Followup-To: Dave Jones <davej@redhat.com>,
	Jamie Lokier <jamie@shareable.org>,
	John Bradford <john@grabjohn.com>, akpm@osdl.org, torvalds@osdl.org,
	linux-kernel@vger.kernel.org
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com> <200309301410.h8UEAEgJ000652@81-2-122-30.bradfords.org.uk> <20030930145854.GD28876@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930145854.GD28876@mail.shareable.org>
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 30, 2003 at 03:58:54PM +0100, Jamie Lokier wrote:

 > (Aside: It is quite an anomaly that those cumbersome floating point
 > instructions are emulated on the older CPUs, yet all the other
 > instructions aren't emulated.  Emulation is very slow, and forcing
 > userspace to just use different code instead is good, but that's just
 > as valid for floating point as it is for MMX, cmpxchg etc.)

There was a patch around a while back that did 486 emulation on 386
kernels. I think it even made into the Mandrake kernel.

 > To be fair, the kernel really ought to just say that and halt.  That
 > is a fine compromise.  It won't make embedded systems folks completely
 > happy, because if you've only got 2MB of NVRAM for your whole kernel
 > _and_ filesystem including user data (think PDA or cellphone), then a
 > hundred bytes here or there is actually worth trimming.

With such tight constraints, why not just use 2.4 (or even 2.2) which
has much lower memory usage and diskspace requirements ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261588AbTI3Pbe (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 11:31:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261587AbTI3Pbe
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 11:31:34 -0400
Received: from mail.jlokier.co.uk ([81.29.64.88]:6022 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261585AbTI3PbP (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 11:31:15 -0400
Date: Tue, 30 Sep 2003 16:30:52 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Dave Jones <davej@redhat.com>, John Bradford <john@grabjohn.com>,
       akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930153052.GE28876@mail.shareable.org>
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com> <20030930140627.GB28876@mail.shareable.org> <20030930145007.GB12812@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930145007.GB12812@redhat.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Dave Jones wrote:
>  > I'm not sure what the fuss is; a strict 386 kernel runs just fine
>  > without any problems on an Athlon.  But anyway...
> 
> Unless it got configured away as proposed in your earlier patch.

No, I don't understand.  What about my patch, or indeed anything else,
stops a "strict 386" kernel from running on an Athlon?

>  > The latter is for distro boots.  The former is for that
>  > 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
>  > everything it can, and no errata thank you.
> 
> Again, 'trimming' away a few hundred bytes of errata workarounds
> is ridiculous when we have bigger fish to fry where we can save
> KBs of .text size, and MB's of runtime memory.

Well I think both are worthwhile.  Low hanging fruit and all that -
this is an example of a small saving that's very clear and easy.

>  > I've not heard of anyone actually wanting a strict 386 kernel lately,
>  > but strict 486 is not so unusual.
> 
> ISTR that current gcc's emit 486 instructions anyway, so its possible
> that with a modern toolchain, you can't *build* a 386 kernel.
> I'm not sure if that got fixed or not, I don't track gcc lists any more.

Afaict GCC has fine targetting for the 386, better than it did years
ago.  It didn't used to use the "leave" instruction, have an option to
optimise for size, or options for selecting exactly which
architectural instruction set it would use.

Anyway, that there is very little difference between 386 and 486 from
an application point of view anyway.  You may be thinking of the
recent C++ ABI debacle, I think it was, which accidentially turned out
to require some instruction emulation in the Debian kernel.  I think
they've fixed it in GCC now.

>  > Just as some people want a P4 optimised kernel, and some people want a
>  > K7 optimised kernel, so some people want a 386 or 486 or Pentium
>  > optimised kernel.  Lowest-common-denominator means it runs on
>  > everything, and isn't really anything to do with 386 any more - that's
>  > not really the lowest-common-denominator, by virtue of the obvious
>  > fact that pure 386 code isn't reliable on all other CPUs.
> 
> Elaborate? "pure 386 code" (whatever that means in your definition)
> should run perfectly reliable on every CPU we care about.

If that were true, why are we talking about needing workarounds for
non-386 chips to work correctly?

The canonical example is the F00F sequence: reliable on a 386, crashes
a Pentium.  That's a fine example of pure 386 code not being reliable
on a higher CPU.  And that's why it isn't safe to run Linux 1.0 on
your Pentium web server.

> So first you argue for compiling out a few hundred bytes of errata
> workaround, now you want to instead compile in checks & printk's
> (which probably add up to not far off the same amount of space).

Oh, I have nothing against __init space :)

>  > By selecting a PII kernel, it is possible to configure out the code
>  > for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
>  > _can_ possibly boot on kernels where the errata are needed, and nary a
>  > printk is emitted for it.  Nasty bugs they are, too.
> 
> Indeed. That's arguably a bug that occured when someone split the
> original CONFIG_M686 into _M686 & MPENTIUMII.

It's a bit more complicated.  It dates from before we had the
"alternative" macro, and it was still cool to optimise spin_unlock()
into the most minimal instruction sequence at compile time.

It's only since then that we've been generalising to "M586 should run
on all later models correctly".  Arguably, tidying up in the process.

Now we could use "alternative" to put the locked store or non-locked
store there and it would not look out of place.

If we're honest, Linux seems to have evolved through the 2.5 series
from "optimise the primitives as tight as reasonable for a target
architecture" to "a few nops here and there won't hurt".  Perhaps
Transmeta's malign influence, as nops cost virtually nothing on those :)

Or perhaps it's because CPU models have branched and don't make a
straight line any more.  So we have to do more run-time checking to
keep it sane.

>  > More generally than the CPU, you can also configure out BLK_DEV_RZ1000
>  > which is another crucial workaround that needs to go in any
>  > lowest-common-denominator kernel.
> 
> I wouldn't look at the history of drivers/ide/ as a shining example of
> good design 8-)

No, but as an example of needing to enable all the workarounds for a
distro boot kernel, it's a glorious gem.  Even now people aren't quite
sure if multi-sector mode or DMA should be enabled by default :)

>  > Basically, if you're building a
>  > distro boot kernel, you must turn on all known workarounds.  That's
>  > certainly lowest-common-denominator, but it's a far cry from the
>  > configuration that a 386-as-firewall user wants.
> 
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole.  After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.

Perhaps it's in a name.  It doesn't help that there's an assumed
linear progression of CPUs to support, up to the point where they
branch off all over the place in feature space.  In the linear part,
CONFIG_M586, CONFIG_M686 etc. seem to mean "support this CPU or
later", whatever later means (and it's not stated exactly).  After the
explosion of different feature directions, they stop meaning that and
just become optimisation knobs, as all the different essential features
are supported at run time.

Personally I think Adrian's patch's heart is in the right place,
simply because the menu options make more sense than the present
rather confusion decision, if you intend to (or might ever, take your
pick) run a kernel compiled for one CPU on another.  I am never sure,
for example, if it's safe to take the hard disk from my K6 and drop it
into a P5MMX box and boot from it.  The kernel config just doesn't
make that clear.

With Adrian's it does, even if the code behind it is a little like
guacamole.  Perhaps the code could be cleaner; I don't see that
individual CPU model support is much different than what we already
have, except for the option to fix features at compile time rather than
run time.

And that gives me an idea.... ;)

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261746AbTI3Qew (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 Sep 2003 12:34:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261748AbTI3Qew
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Sep 2003 12:34:52 -0400
Received: from hermes.fachschaften.tu-muenchen.de ([129.187.202.12]:15331 "HELO
	hermes.fachschaften.tu-muenchen.de") by vger.kernel.org with SMTP
	id S261746AbTI3Qes (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Sep 2003 12:34:48 -0400
Date: Tue, 30 Sep 2003 18:34:41 +0200
From: Adrian Bunk <bunk@fs.tum.de>
To: Dave Jones <davej@redhat.com>, Jamie Lokier <jamie@shareable.org>,
       John Bradford <john@grabjohn.com>, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20030930163441.GP295@fs.tum.de>
References: <200309300817.h8U8HGrf000881@81-2-122-30.bradfords.org.uk> <20030930133113.GC23333@redhat.com> <20030930140627.GB28876@mail.shareable.org> <20030930145007.GB12812@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030930145007.GB12812@redhat.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 30, 2003 at 03:50:08PM +0100, Dave Jones wrote:
>...
>  > Basically, if you're building a
>  > distro boot kernel, you must turn on all known workarounds.  That's
>  > certainly lowest-common-denominator, but it's a far cry from the
>  > configuration that a 386-as-firewall user wants.
> 
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole.  After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.
>...

Referring to the latest patch I sent:

arch/i386/Kconfig:
The only problems seem to be some CPU_ONLY_* derived symbols I haven't 
yet found a better solution for.

arch/i386/Makefile:
There are two ifdefs to deal with Pentium 4 and K7/K8 selected at the 
same time:
ifdef CONFIG_CPU_PENTIUM4
  cpuflags-$(CONFIG_CPU_K{7,8})    := ...
else
  cpuflags-$(CONFIG_CPU_K{7,8})    := ...
endif

That's perhaps not optimal but IMHO not that bad.

The dozens of ifdefs were in other areas where I tried to add some 
additional space optimizations. It was a mistake to put them into the 
same patch and in the latest patches I sent they were already separated 
and they are _not_ required for the CPU selection scheme.

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264574AbTLCPo5 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 3 Dec 2003 10:44:57 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264603AbTLCPo4
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 3 Dec 2003 10:44:56 -0500
Received: from chaos.analogic.com ([204.178.40.224]:34439 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP id S264574AbTLCPoy
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Dec 2003 10:44:54 -0500
Date: Wed, 3 Dec 2003 10:43:45 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <7A25937D23A1E64C8E93CB4A50509C2A0310EFAA@stca204a.bus.sc.rolm.com>
Message-ID: <Pine.LNX.4.53.0312031037440.17092@chaos>
References: <7A25937D23A1E64C8E93CB4A50509C2A0310EFAA@stca204a.bus.sc.rolm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 3 Dec 2003, Bloch, Jack wrote:

> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com


Because it doesn't happen! You are likely polluting the errno
variable either with another system call before you test it
or by not including the correct header file (errno may be a
MACRO).


Try this program:


#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>

int main(int args, char *argv[])
{
    int fd, save_errno;
    if(args < 2) {
        fprintf(stderr, "Usage:\n%s <filename>\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    if((fd = open(argv[1], O_RDONLY)) < 0) {
        save_errno = errno;
        perror("open");
        fprintf(stderr, "Was %d (%s)\n", save_errno, strerror(save_errno));
        exit(EXIT_FAILURE);
    }
    (void)close(fd);
    return 0;
}

Script started on Wed Dec  3 10:41:24 2003
# ./xxx /dev/XXX
open: No such file or directory
Was 2 (No such file or directory)
# ./xxx /dev/VXI
open: Operation not supported by device
Was 19 (Operation not supported by device)
# exit
exit
Script done on Wed Dec  3 10:42:12 2003

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264599AbTLCQDw (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 3 Dec 2003 11:03:52 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264603AbTLCQDw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 3 Dec 2003 11:03:52 -0500
Received: from fw.osdl.org ([65.172.181.6]:54956 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S264599AbTLCQDw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Dec 2003 11:03:52 -0500
Date: Wed, 3 Dec 2003 08:03:44 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <7A25937D23A1E64C8E93CB4A50509C2A0310EFAA@stca204a.bus.sc.rolm.com>
Message-ID: <Pine.LNX.4.58.0312030802420.5258@home.osdl.org>
References: <7A25937D23A1E64C8E93CB4A50509C2A0310EFAA@stca204a.bus.sc.rolm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?

Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?

		Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S265066AbTLCQT7 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 3 Dec 2003 11:19:59 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265071AbTLCQT7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 3 Dec 2003 11:19:59 -0500
Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]:55954 "EHLO
	brmx1.fl.icn.siemens.com") by vger.kernel.org with ESMTP
	id S265066AbTLCQT5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Dec 2003 11:19:57 -0500
Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A0310EFAC@stca204a.bus.sc.rolm.com>
From: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
To: "'Linus Torvalds'" <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail
Date: Wed, 3 Dec 2003 08:19:51 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Thanks,

I found the problem. I do have errno.h included. I was doing a read of errno
after calling perror. If I read it directly after getting the neagtive 0ne
back, it contains the right value.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Wednesday, December 03, 2003 11:04 AM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail




On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it
contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?

Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?

		Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263561AbTLJNRZ (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 10 Dec 2003 08:17:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263564AbTLJNRZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 10 Dec 2003 08:17:25 -0500
Received: from mail3.ithnet.com ([217.64.64.7]:15829 "HELO
	heather-ng.ithnet.com") by vger.kernel.org with SMTP
	id S263561AbTLJNRW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 10 Dec 2003 08:17:22 -0500
X-Sender-Authentication: net64
Date: Wed, 10 Dec 2003 14:17:19 +0100
From: Stephan von Krawczynski <skraw@ithnet.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: paul@clubi.ie, marcelo.tosatti@cyclades.com, thornber@sistina.com,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-Id: <20031210141719.1c8d5033.skraw@ithnet.com>
In-Reply-To: <20031210120336.GU8039@holomorphy.com>
References: <20031210120336.GU8039@holomorphy.com>
Organization: ith Kommunikationstechnik GmbH
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 10 Dec 2003 04:03:36 -0800
William Lee Irwin III <wli@holomorphy.com> wrote:

> On Tue, 9 Dec 2003, William Lee Irwin III wrote:
> >>> Just apply the patch if you're for some reason terrified of 2.6.
> 
> On Wed, 10 Dec 2003 00:15:17 +0000 (GMT) Paul Jakma <paul@clubi.ie> wrote:
> >> Or get RedHat or Fedora to apply the patch.
> 
> On Wed, Dec 10, 2003 at 11:49:28AM +0000, skraw@ithnet.com wrote:
> > There it is again, this /dev/null argument.
> > "Multi-billion dollar companies" have gone bancrupt on the simple
> > fact that diversification of one product can rattle customers/users
> > to a degree that they in fact decide against the whole product range.
> > IOW go on with the idea to spread around an unknown number of kernel
> > versions and you can be sure that linux as a whole will greatly suffer.
> > This is a "user" issue, not a "developer" issue of course. Developers
> > can apply any kind of patches they like, but don't go and tell the
> > vast user base to "just apply patch xyz". They won't honor this at
> > all, your level of acceptance will dramatically drop.
> 
> One of the main reasons to have an open source OS is customization.
> Arguing that it's not truly feasible to customize will not hold water.

Are you calling a user-configured (not user-patched) kernel "customized" or
not?
_The_ top reason (at least when reading Al's posts :-) is probably that the
source is cross-checked by many eyes. If you create a infinite number of
patched kernel-versions it is obvious you will loose this primary advantage.
The more versions the fewer cross-checking.
IOW a "customized" but instable OS values exactly zero.

> Pretty much every "productized" version of Linux is heavily customized
> to get some kind of value-add. There's no reason to bother mainline
> with this; if it's a serious user issue of that magnitude vendors will
> pick it up.

"Serious" is a subjective argument, therefore different people see different
issues as serious. In my opinion a kernel.org kernel should cover most if not
all possible stable customizations, see it as a pool.
So my primary question for inclusion would not be "what is it worth?" but "does
it do any harm?". I am not god, therefore I do not and can not judge 
"worthness". Can you?

Regards,
Stephan


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S265153AbTLWOyg (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 23 Dec 2003 09:54:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265154AbTLWOyf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 23 Dec 2003 09:54:35 -0500
Received: from mail.zmailer.org ([62.78.96.67]:41099 "EHLO mail.zmailer.org")
	by vger.kernel.org with ESMTP id S265153AbTLWOye (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 23 Dec 2003 09:54:34 -0500
Date: Tue, 23 Dec 2003 16:54:26 +0200
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: dublinux <dublinux@box.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20031223145426.GR1343@mea-ext.zmailer.org>
References: <20031223151622.26d0bf10.dublinux@box.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031223151622.26d0bf10.dublinux@box.it>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Folks, I don't understand you...
In EVERY list posting there are explicite instructions
of how to unsubscribe, and STILL people do it wrong...

Do tell us (postmaster@vger.kernel.org) if you do find that
there is something confusing, and should be improved.

  /Matti Aarnio -- one of  <postmaster@vger.kernel.org>

On Tue, Dec 23, 2003 at 03:16:22PM +0100, dublinux wrote:
> Date:	Tue, 23 Dec 2003 15:16:22 +0100
> From:	dublinux <dublinux@box.it>
> To:	linux-kernel@vger.kernel.org
> 
> unsubscribe linux-kernel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262750AbTLWToT (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 23 Dec 2003 14:44:19 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262760AbTLWToT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 23 Dec 2003 14:44:19 -0500
Received: from [200.55.45.230] ([200.55.45.230]:64667 "EHLO smtp.bensa.ar")
	by vger.kernel.org with ESMTP id S262750AbTLWToM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 23 Dec 2003 14:44:12 -0500
From: Norberto Bensa <nbensa@gmx.net>
To: linux-kernel@vger.kernel.org
Subject: Re: your mail
Date: Tue, 23 Dec 2003 14:36:27 -0300
User-Agent: KMail/1.5.4
References: <20031223151622.26d0bf10.dublinux@box.it> <20031223145426.GR1343@mea-ext.zmailer.org>
In-Reply-To: <20031223145426.GR1343@mea-ext.zmailer.org>
Cc: Matti Aarnio <matti.aarnio@zmailer.org>
MIME-Version: 1.0
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_e0H6/5nxK18ZMBG";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200312231436.30097.nbensa@gmx.net>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--Boundary-02=_e0H6/5nxK18ZMBG
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Matti Aarnio wrote:
> Folks, I don't understand you...
> In EVERY list posting there are explicite instructions
> of how to unsubscribe, and STILL people do it wrong...

People doesn't read.

Regards,
Norberto

=2D-=20
Linux 2.6.0-mm1 Pentium III (Coppermine) GenuineIntel GNU/Linux
 14:35:46 up 39 min,  1 user,  load average: 0.34, 0.18, 0.13

--Boundary-02=_e0H6/5nxK18ZMBG
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/6H0eFXVF50lmS74RAmGOAJ9R52m0hUfnB6ZTjr78/eQddzLd3QCfSLfd
7IFgl+TrffdUwJ/nObHqjnA=
=jtuP
-----END PGP SIGNATURE-----

--Boundary-02=_e0H6/5nxK18ZMBG--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264323AbTLZW1q (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 26 Dec 2003 17:27:46 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264329AbTLZW1q
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 26 Dec 2003 17:27:46 -0500
Received: from fw.osdl.org ([65.172.181.6]:40889 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S264323AbTLZW1n (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 26 Dec 2003 17:27:43 -0500
Date: Fri, 26 Dec 2003 14:27:39 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
To: caszonyi@rdslink.ro
cc: linux-kernel@vger.kernel.org, kraxel@bytesex.org
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.53.0312262105560.537@grinch.ro>
Message-ID: <Pine.LNX.4.58.0312261419230.14874@home.osdl.org>
References: <Pine.LNX.4.53.0312262105560.537@grinch.ro>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Fri, 26 Dec 2003 caszonyi@rdslink.ro wrote:
> 
> I was trying to capture a tv program  with mencoder when the oops occured
> a couple  of hours later the system froze without leaving a single trace
> in logs. I was able to reboot with SysRq.
> 
> Programs versions, config and dmesg are attached.

Looks like this loop:

		....
                        while (voffset >= sg_dma_len(vsg)) {
                                voffset -= sg_dma_len(vsg);
                                vsg++;
                        }
		....

and in particular, it's the "sg_dma_len()" access that oopses, apparently 
because vsg was stale to begin with, or because it incremented past the 
last pointer.

The pointer that fails (0xc4bea00c) looks reasonable, so it's almost
certainly due to CONFIG_PAGE_DEBUG showing some kind of use-after-free
problem (ie the pointer is stale, and the memory has already been freed).

I suspect the problem is that 

	"voffset >= sg_dma_len(vsg)"

test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will 
test one more iteration (when "voffset" is 0), and that iteration may be 
past the end of the "vsg" array.

I suspect the fix might be to change the test to

	"voffset && voffset >= sg_dma_len(vsg)"

to make sure that we never access vsg past the end of the array.
		

		Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S265161AbUAEPZi (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 5 Jan 2004 10:25:38 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265168AbUAEPZh
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 5 Jan 2004 10:25:37 -0500
Received: from hirsch.in-berlin.de ([192.109.42.6]:4250 "EHLO
	hirsch.in-berlin.de") by vger.kernel.org with ESMTP id S265161AbUAEPZf
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 5 Jan 2004 10:25:35 -0500
X-Envelope-From: kraxel@bytesex.org
Date: Mon, 5 Jan 2004 11:59:15 +0100
From: Gerd Knorr <kraxel@bytesex.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: caszonyi@rdslink.ro, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040105105915.GU15106@bytesex.org>
References: <Pine.LNX.4.53.0312262105560.537@grinch.ro> <Pine.LNX.4.58.0312261419230.14874@home.osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0312261419230.14874@home.osdl.org>
User-Agent: Mutt/1.5.3i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> 		....
>                         while (voffset >= sg_dma_len(vsg)) {
>                                 voffset -= sg_dma_len(vsg);
>                                 vsg++;
>                         }
> 		....

> I suspect the problem is that 
> 
> 	"voffset >= sg_dma_len(vsg)"
> 
> test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will 
> test one more iteration (when "voffset" is 0), and that iteration may be 
> past the end of the "vsg" array.

That certainly makes sense, the 'v' plane is the last one in the memory
block for the video frame to be captured, so voffset / vsg will walk to
the last sg entry and may overrun described.  Good catch, I'm impressed.

> I suspect the fix might be to change the test to
> 
> 	"voffset && voffset >= sg_dma_len(vsg)"

Merged into my tree, thanks.

still busy with the xmas mail backlog,

  Gerd


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261500AbUBKBJr (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 10 Feb 2004 20:09:47 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262228AbUBKBJr
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 10 Feb 2004 20:09:47 -0500
Received: from gaia.cela.pl ([213.134.162.11]:5124 "EHLO gaia.cela.pl")
	by vger.kernel.org with ESMTP id S261500AbUBKBJp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Feb 2004 20:09:45 -0500
Date: Wed, 11 Feb 2004 02:09:42 +0100 (CET)
From: Maciej Zenczykowski <maze@cela.pl>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <7A25937D23A1E64C8E93CB4A50509C2A0310F0A7@stca204a.bus.sc.rolm.com>
Message-ID: <Pine.LNX.4.44.0402110206090.13719-100000@gaia.cela.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 10 Feb 2004, Bloch, Jack wrote:

> I have a system with 2GB of memory. One of my processes calls mmap to try to
> map a 100MB file into memory. This calls fails with -ENOMEM. I rebuilt the
> kernel with a few debug printk statements in mmap.c to see where the failure
> was occurring it occurred in the function arch_get_unmapped_area. the code
> is as follows:
> 
> for (vma = find_vma(mm, addr); ; vma = vma->vm_next) {
> 		/* At this point:  (!vma || addr < vma->vm_end). */
> 		unsigned long __heap_stack_gap;
> 		if (TASK_SIZE - len < addr)
>                 { 

it's valid there's no point in searching further for an area of at least 
len bytes.  The user area is 0 .. TASK_SIZE-1.  The addr is the address 
currently being checked, the len is the requested length.  if addr+len is 
greater or equal to TASK_SIZE then the current addr (which is increasing 
within this loop) already causes such a mapping to overflow into kernel 
space (exceeds the TASK_SIZE virtual address limit).  This is precisely as 
expected.

I'd assume your program has fragmented memory to such a level that a 
single consecutive 100 MB area is no longer free (not that hard to do, 
since TASK_SIZE is 3 GB).

Cheers,
MaZe.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267088AbUBMSLW (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 13 Feb 2004 13:11:22 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267139AbUBMSLV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 13 Feb 2004 13:11:21 -0500
Received: from gaia.cela.pl ([213.134.162.11]:50701 "EHLO gaia.cela.pl")
	by vger.kernel.org with ESMTP id S267088AbUBMSLT (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 13 Feb 2004 13:11:19 -0500
Date: Fri, 13 Feb 2004 19:11:10 +0100 (CET)
From: Maciej Zenczykowski <maze@cela.pl>
To: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <7A25937D23A1E64C8E93CB4A50509C2A0310F0B9@stca204a.bus.sc.rolm.com>
Message-ID: <Pine.LNX.4.44.0402131908200.12513-100000@gaia.cela.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using the
> up to the 0xC0000000 of space. It is no longer possible for this process to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267177AbUBMTOb (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 13 Feb 2004 14:14:31 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267182AbUBMTOb
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 13 Feb 2004 14:14:31 -0500
Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]:27576 "EHLO
	brmx1.fl.icn.siemens.com") by vger.kernel.org with ESMTP
	id S267177AbUBMTO0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 13 Feb 2004 14:14:26 -0500
Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A0310F0BA@stca204a.bus.sc.rolm.com>
From: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
To: "'Maciej Zenczykowski'" <maze@cela.pl>
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail
Date: Fri, 13 Feb 2004 11:14:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Yes, your assumtion about the 1GB is correct.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267187AbUBMTXw (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 13 Feb 2004 14:23:52 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267188AbUBMTXw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 13 Feb 2004 14:23:52 -0500
Received: from mail.siemenscom.com ([12.146.131.10]:39646 "EHLO
	mail.siemenscom.com") by vger.kernel.org with ESMTP id S267187AbUBMTXt
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 13 Feb 2004 14:23:49 -0500
Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A0310F0BB@stca204a.bus.sc.rolm.com>
From: "Bloch, Jack" <Jack.Bloch@icn.siemens.com>
To: "'Maciej Zenczykowski'" <maze@cela.pl>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: your mail
Date: Fri, 13 Feb 2004 11:23:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

By the way shouldn't a munmap call really free the memory. I have an strace
showing that the process calls munmap a lot but I do not seeany gaps in the
map file

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Bloch, Jack 
Sent: Friday, February 13, 2004 2:14 PM
To: 'Maciej Zenczykowski'
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail


Yes, your assumtion about the 1GB is correct.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262258AbUBXOmc (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 24 Feb 2004 09:42:32 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262260AbUBXOmc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 24 Feb 2004 09:42:32 -0500
Received: from chaos.analogic.com ([204.178.40.224]:8833 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP id S262258AbUBXOmU
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 24 Feb 2004 09:42:20 -0500
Date: Tue, 24 Feb 2004 09:44:03 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: Jim Deas <jdeas0648@jadsystems.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <200402240558.AA3585540272@jadsystems.com>
Message-ID: <Pine.LNX.4.53.0402240931310.8074@chaos>
References: <200402240558.AA3585540272@jadsystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 24 Feb 2004, Jim Deas wrote:

> Can someone point me in the right direction.
> I am getting a oops on a driver I am porting from 2.4 to 2.6.2 kernel.
> I have expanded the file_operations structures and have a driver that
> loads and inits the hardware but when I call the open function I
> get an oops. The best I can track it is
>

Fix your line-warp!

> EIP 0060:[c0188954]
> chrdev_open +0x104
>
> What is the best debug tool to put this oops information in clear
> sight? It appears to never get to my modules open routine so I am
> at a debugging crossroad. What is the option on a kernel compile
> to get the compile listing so I can see what is at 0x104 in this
> block of code?
>

Nothing is going to help with that EIP with a segment value of
0x60. It looks like some dumb coding error, using a pointer
that disappeared after the module init function. In other
words, it's probably something like:

int __init init_module()
{
    struct file_operations fops;
    mset(&fops, 0x00, sizeof(fops));
    fops.open = open;
    fops.release = close;
    fops.owner = THIS_MODULE;
    register_chrdev(DEV_MAJOR, dev, &fops);
}

So, everything in init_module is GONE. Your program calls open()
and the pointer in the kernel gets dereferenced to junk.

There are kernel debugging tools, however I have found that
the most useful tools are printk() and some discipline.

In the case of code above, don't just change the declaration
of the fops object to static. Instead, move it outside the
function, so it's obviously where it won't go away.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262667AbUCOX1a (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 15 Mar 2004 18:27:30 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262649AbUCOX1a
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 15 Mar 2004 18:27:30 -0500
Received: from chaos.analogic.com ([204.178.40.224]:21388 "EHLO
	chaos.analogic.com") by vger.kernel.org with ESMTP id S262667AbUCOXXA
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 15 Mar 2004 18:23:00 -0500
Date: Mon, 15 Mar 2004 18:26:35 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
X-X-Sender: root@chaos
Reply-To: root@chaos.analogic.com
To: Kevin Leung <sac98993@hotmail.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <Law9-F89Xsn2Yf0scL90004e4c8@hotmail.com>
Message-ID: <Pine.LNX.4.53.0403151813590.2223@chaos>
References: <Law9-F89Xsn2Yf0scL90004e4c8@hotmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 15 Mar 2004, Kevin Leung wrote:

> Hello All,
>
> I am very new to Linux and am working on a project. The nature of the
> project is to essentially record all process/thread scheduling activity for
> use in a later application. I wanted to know if any experts out there knew
> of any libraries that could essentially "monitor" or "listen" for any
> scheduling changes made. For instance if the kernel decides to set process A
> from "sleeping" to "running" and process B from "running" to "sleeping", I
> wanted to know if there was a function that could generate an immediate
> notification of this event.

No. FYI, there are hundreds-of-thousands of such "events" per second
of operation! Basically, any time some task is waiting for I/O its
CPU is taken away and given to somebody else. This is what "sleeping"
usually means. Once the I/O completes, the task gets the CPU
again and that's what "running" means. If you were to instrument
these two state-changes for all tasks, it would certainly leave
only a new percent of CPU available for the tasks. This would
royally screw up the meaning of anything you were trying to
instrument.

> Priority change information is also desireable.

If you mean the dynamic priority that keeps changing until
the task is executed, no. If you mean priority like
'nice', you can instrument the sys-call.

> The more aspects which trigger notificaiton, the better. As a first attempt,

There is a kernel logging daemon that writes 'printk' messages. This
works by having a user-mode daemon open and read /proc/kmsg. You can
make a similar communications interface, using the existing daemon
as a template, that will instrument anything you want.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261551AbUDISNM (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 9 Apr 2004 14:13:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261597AbUDISNM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 9 Apr 2004 14:13:12 -0400
Received: from twin.uoregon.edu ([128.223.214.27]:13461 "EHLO twin.uoregon.edu")
	by vger.kernel.org with ESMTP id S261551AbUDISNG (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 9 Apr 2004 14:13:06 -0400
Date: Fri, 9 Apr 2004 11:12:57 -0700 (PDT)
From: Joel Jaeggli <joelja@darkwing.uoregon.edu>
X-X-Sender: joelja@twin.uoregon.edu
To: Martin Knoblauch <knobi@knobisoft.de>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040409175403.91924.qmail@web13904.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0404091100520.1074-100000@twin.uoregon.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 9 Apr 2004, Martin Knoblauch wrote:

> >I was wondering if for linux or better for a linux filesystem
> >there is something like dynamic swapping of files possible.
> >For explanation: I habeaccess to an Infinstor via NFS and
> >linux is runnig there. This server has a nice funtion I'd
> >like to have: if there are files that are not used for a
> >specified time (i.e. 30 days) they are moved to another storage
> >(disk and after that to an streamer tape) and are replaced
> >by some kind of 'link'. So if you look at your directory you
> >can see everything that was there, but if you try to open it,
> >you have to wait a moment (some seconds if the file was
> >swapped to another disk) oder just another moment (some
> >minutes if the file is on a tape) and then it restored at
> >it's old place.
> >
> 
>  Good description of a HSM (Hierarchical Storage Management)
> System.
> 
> >So is there anything which provides such a feature? By now
> >I have a little script that moves such files out of the way and
> >replaces them by links. But restoring is somewhat harder and
> >it's not automatic.
> >
> >Any ideas?
> >

part of the thing for us (my group at UO) right now, is tape robots aren't
cheaper than disk, so a lot of our offline/near-line backup is slowly
moving in that direction... 1TB lto jukeboxs cost order of $8-9K ea and
the driver for your commercial tabe-backup software can cost nearly that
much on top of it, but I can put 3.5TB of disk in a 5u enclosure and
locate in some other building for a similar price if not less. Even If buy
it in something like a netapp filer it's still only around $10,000 a TB so
HSM systems involving tape don't really have the same apeal as when we
were paying $1200ea for 4GB scsi disks. If I had sunk costs in something
like a storagetek powerhorn with 6000 tape capacity I might think a little
differently but I suspect your situation is closer to mine that it is to
the sorts of people who buy those.

>  Really depends. As far as I know thare are no "free" HSM Systems
> out there for Linux The only one that I am faintly familiar with
> that runs on Linux is StorNext from ADIC. Definitely not free.
> 
>  DMF/Irix may now be ported to Linux (Altix/IA64), but I doubt
> it will be free.
> 
>  Sun is most likely not (yet) interested in doing a Linux port
> of SAM-FS (there are still Sparc/Solaris Machines to sell).
> And it won't be free (my guess).
> 
>  Tivoli/IBM and UniTree are also sold for Linux. Again "sold" is
> the important word
> 
> Martin
> 
> 
> =====
> ------------------------------------------------------
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www:   http://www.knobisoft.de
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263480AbUDMNqi (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 13 Apr 2004 09:46:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263493AbUDMNqi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 13 Apr 2004 09:46:38 -0400
Received: from mx1.redhat.com ([66.187.233.31]:19126 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S263480AbUDMNqd (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 13 Apr 2004 09:46:33 -0400
Date: Tue, 13 Apr 2004 09:46:11 -0400 (EDT)
From: James Morris <jmorris@redhat.com>
X-X-Sender: jmorris@thoron.boston.redhat.com
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
cc: "David S. Miller" <davem@redhat.com>, <netdev@oss.sgi.com>,
       =?iso-2022-jp?Q?YOSHIFUJI_Hideaki_=2F_=1B$B5HF#1QL=40=1B=28B?= 
	<yoshfuji@linux-ipv6.org>,
       <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <200404121623.42558.vda@port.imtp.ilyichevsk.odessa.ua>
Message-ID: <Xine.LNX.4.44.0404130945460.14102-100000@thoron.boston.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 12 Apr 2004, Denis Vlasenko wrote:

> According to my measurements,
> 
> ip_vs_control_add() (from include/net/ip_vs.h) is called twice
> and
> sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times
> from various kernel .c files.
> 
> Both these includes generate more than 500 bytes of code on x86.
> 
> These patches uninline them. Please apply.

What kind of performance impact (if any) does this patch have?


- James
-- 
James Morris
<jmorris@redhat.com>



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263100AbUD2DWI@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263100AbUD2DWI (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 28 Apr 2004 23:22:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263088AbUD2DWI
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 28 Apr 2004 23:22:08 -0400
Received: from mailoff.mtu.edu ([141.219.70.111]:40683 "EHLO mailoff.mtu.edu")
	by vger.kernel.org with ESMTP id S263125AbUD2DV7 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 28 Apr 2004 23:21:59 -0400
Date: Wed, 28 Apr 2004 23:21:52 -0400
From: Jon <jon787@tesla.resnet.mtu.edu>
To: whitehorse@mustika.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040429032151.GE17234@tesla.resnet.mtu.edu>
Reply-To: jadevree@mtu.edu
References: <S263020AbUD2DDO/20040429030314Z+1040@vger.kernel.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="3O1VwFp74L81IIeR"
Content-Disposition: inline
In-Reply-To: <S263020AbUD2DDO/20040429030314Z+1040@vger.kernel.org>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--3O1VwFp74L81IIeR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 28, 2004 at 11:03:08PM -0400, whitehorse@mustika.net wrote:
> dear Sir,
>  I have a problem in compiling kernel 2.6.4 from kernel 2.4.19. I use
>  Debian woody. When I rebooting new kernel, some message occur such:
>  "modprobe: QM_MODULES: function not implemented"
>  and I can't load my modules when boot. I would like to waiting any one w=
ho
>  answer this. Please send to this mail. Thanks
>=20
>  Best regards,
>=20
>  Hafid
>  Indonesia
>=20
You need to install module-init-tools which is not in Debian Woody
A backport of it for x86 machines is here
http://www.backports.org/debian/dists/woody/module-init-tools/
--=20
Jon
http://tesla.resnet.mtu.edu
The only meaning in life is the meaning you create for it.

--3O1VwFp74L81IIeR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAkHTPrd+yBMYSKYIRAnMuAJ9RM36TGWQvUVGQ2/9sx3jLii6GvQCgnpsJ
2+v7u5UhboHb5WzilcMbmL8=
=G7xs
-----END PGP SIGNATURE-----

--3O1VwFp74L81IIeR--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263928AbUEXWaZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263928AbUEXWaZ (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 18:30:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264723AbUEXWaZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 18:30:25 -0400
Received: from MAIL.13thfloor.at ([212.16.62.51]:33189 "EHLO mail.13thfloor.at")
	by vger.kernel.org with ESMTP id S263928AbUEXWaX (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 18:30:23 -0400
Date: Tue, 25 May 2004 00:30:22 +0200
From: Herbert Poetzl <herbert@13thfloor.at>
To: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040524223022.GA29595@MAIL.13thfloor.at>
Mail-Followup-To: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>,
	linux-kernel@vger.kernel.org
References: <67B3A7DA6591BE439001F2736233351202B47E6E@xch-nw-28.nw.nos.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <67B3A7DA6591BE439001F2736233351202B47E6E@xch-nw-28.nw.nos.boeing.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
> 
> Dynamically change the priorities of processes (up and down)
> Lock processes in memory
> Can change process cpu affinity
> 
> Anyone got any ideas about how I could start doing this?  (I'm new to
> kernel development, btw.)

check the kernel capability system ...
(it's quite simple)

#define CAP_SYS_NICE         23
#define CAP_IPC_LOCK         14

cpu scheduler affinity isn't part of 2.4 AFAIK
so there is no easy way to 'control' it ...

HTH,
Herbert

> Thanks,
> 
> Joe Laughlin
> Phantom Works - Integrated Technology Development Labs 
> The Boeing Company
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S264453AbUEXWeF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264453AbUEXWeF (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 18:34:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264550AbUEXWeF
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 18:34:05 -0400
Received: from fw.osdl.org ([65.172.181.6]:27580 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S264453AbUEXWeA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 18:34:00 -0400
Date: Mon, 24 May 2004 15:33:59 -0700
From: Chris Wright <chrisw@osdl.org>
To: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040524153359.N22989@build.pdx.osdl.net>
References: <67B3A7DA6591BE439001F2736233351202B47E6E@xch-nw-28.nw.nos.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <67B3A7DA6591BE439001F2736233351202B47E6E@xch-nw-28.nw.nos.boeing.com>; from Joseph.V.Laughlin@boeing.com on Mon, May 24, 2004 at 03:20:33PM -0700
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
> 
> Dynamically change the priorities of processes (up and down)

Requires CAP_SYS_NICE.

> Lock processes in memory

Currently requires CAP_IPC_LOCK.  However, this one is already been
done using rlimits (at least via mlock() and friends, SHM_LOCK has
different issue).

> Can change process cpu affinity

Requires CAP_SYS_NICE (but I believe this was a 2.6 feature).

> Anyone got any ideas about how I could start doing this?  (I'm new to
> kernel development, btw.)

There's a few approaches floating about.  Probably the simplest is to
disable the checks globally, but this will also be less secure.  I have
an example of this in 2.6 if you'd like.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S264206AbUEXWgN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264206AbUEXWgN (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 18:36:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264550AbUEXWgM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 18:36:12 -0400
Received: from lindsey.linux-systeme.com ([62.241.33.80]:55818 "EHLO
	mx00.linux-systeme.com") by vger.kernel.org with ESMTP
	id S264206AbUEXWgE (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 18:36:04 -0400
From: Marc-Christian Petersen <m.c.p@kernel.linux-systeme.com>
Organization: Linux-Systeme GmbH
To: linux-kernel@vger.kernel.org
Subject: Re: your mail
Date: Tue, 25 May 2004 00:34:43 +0200
User-Agent: KMail/1.6.2
Cc: Herbert Poetzl <herbert@13thfloor.at>,
       "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
References: <67B3A7DA6591BE439001F2736233351202B47E6E@xch-nw-28.nw.nos.boeing.com> <20040524223022.GA29595@MAIL.13thfloor.at>
In-Reply-To: <20040524223022.GA29595@MAIL.13thfloor.at>
X-Operating-System: Linux 2.6.5-wolk3.0 i686 GNU/Linux
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200405250034.43127@WOLK>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday 25 May 2004 00:30, Herbert Poetzl wrote:

Hi Joseph,

> > Dynamically change the priorities of processes (up and down)
> > Lock processes in memory
> > Can change process cpu affinity
> > Anyone got any ideas about how I could start doing this?  (I'm new to
> > kernel development, btw.)
> check the kernel capability system ...
> (it's quite simple)
> #define CAP_SYS_NICE         23
> #define CAP_IPC_LOCK         14
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...

at least I have a patch in my 2.4-tree where a user in a predefined GID 
(changeable via /proc) can change his/her nice of his/her own processes up 
and down.

ciao, Marc

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263687AbUEXXFP@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263687AbUEXXFP (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 19:05:15 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264409AbUEXXFO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 19:05:14 -0400
Received: from blv-smtpout-01.boeing.com ([130.76.32.69]:22430 "EHLO
	blv-smtpout-01.boeing.com") by vger.kernel.org with ESMTP
	id S263687AbUEXXFH convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 19:05:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: your mail
Date: Mon, 24 May 2004 16:04:43 -0700
Message-ID: <67B3A7DA6591BE439001F2736233351202B47E76@xch-nw-28.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: your mail
Thread-Index: AcRB3rWxS3t/fSZbQyuzYPQV2Avy4gABIPXw
From: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
To: "Herbert Poetzl" <herbert@13thfloor.at>
Cc: <linux-kernel@vger.kernel.org>
X-OriginalArrivalTime: 24 May 2004 23:04:44.0030 (UTC) FILETIME=[805EE1E0:01C441E3]
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Herbert Poetzl [mailto:herbert@13thfloor.at] 
> Sent: Monday, May 24, 2004 3:30 PM
> To: Laughlin, Joseph V
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
> 
> 
> On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > I've been tasked with modifying a 2.4 kernel so that a 
> non-root user 
> > can do the following:
> > 
> > Dynamically change the priorities of processes (up and down) Lock 
> > processes in memory Can change process cpu affinity
> > 
> > Anyone got any ideas about how I could start doing this?  
> (I'm new to 
> > kernel development, btw.)
> 
> check the kernel capability system ...
> (it's quite simple)
> 
> #define CAP_SYS_NICE         23
> #define CAP_IPC_LOCK         14
> 
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...
> 

Currently, we're using sched_setaffinity() to control it, which existed
in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
like non-root users to be able to change the affinity.)

Joe


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263731AbUEXXNY@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263731AbUEXXNY (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 19:13:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263862AbUEXXNY
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 19:13:24 -0400
Received: from gate.firmix.at ([80.109.18.208]:28548 "EHLO gate.firmix.at")
	by vger.kernel.org with ESMTP id S263731AbUEXXNX (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 19:13:23 -0400
Subject: RE: your mail
From: Bernd Petrovitsch <bernd@firmix.at>
To: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>,
       linux-kernel@vger.kernel.org
In-Reply-To: <67B3A7DA6591BE439001F2736233351202B47E76@xch-nw-28.nw.nos.boeing.com>
References: <67B3A7DA6591BE439001F2736233351202B47E76@xch-nw-28.nw.nos.boeing.com>
Content-Type: text/plain
Organization: http://www.firmix.at/
Message-Id: <1085440399.9710.10.camel@gimli.at.home>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 25 May 2004 01:13:19 +0200
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > -----Original Message-----
[...]
> > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > > I've been tasked with modifying a 2.4 kernel so that a 
> > non-root user 
> > > can do the following:
> > > 
> > > Dynamically change the priorities of processes (up and down) Lock 
> > > processes in memory Can change process cpu affinity
[...]
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)

And using sudo or setuid Binaries?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263663AbUEXXPp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263663AbUEXXPp (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 19:15:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263875AbUEXXPp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 19:15:45 -0400
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]:55724 "EHLO
	stl-smtpout-01.boeing.com") by vger.kernel.org with ESMTP
	id S263663AbUEXXPn convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 19:15:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: your mail
Date: Mon, 24 May 2004 16:15:26 -0700
Message-ID: <67B3A7DA6591BE439001F2736233351202B47E7E@xch-nw-28.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: your mail
Thread-Index: AcRB5LXaMmfCvJn3TiiL2CJ5/dNPnwAADGhg
From: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
To: "Bernd Petrovitsch" <bernd@firmix.at>, <linux-kernel@vger.kernel.org>
X-OriginalArrivalTime: 24 May 2004 23:15:26.0318 (UTC) FILETIME=[FF3440E0:01C441E4]
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Bernd Petrovitsch [mailto:bernd@firmix.at] 
> Sent: Monday, May 24, 2004 4:13 PM
> To: Laughlin, Joseph V; linux-kernel@vger.kernel.org
> Subject: RE: your mail
> 
> 
> On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > > -----Original Message-----
> [...]
> > > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, 
> Joseph V wrote:
> > > > I've been tasked with modifying a 2.4 kernel so that a
> > > non-root user
> > > > can do the following:
> > > > 
> > > > Dynamically change the priorities of processes (up and 
> down) Lock
> > > > processes in memory Can change process cpu affinity
> [...]
> > Currently, we're using sched_setaffinity() to control it, which 
> > existed in our 2.4.19 kernel.  (but, you have to be root to use it, 
> > and we'd like non-root users to be able to change the affinity.)
> 
> And using sudo or setuid Binaries?
> 
> 	Bernd
> -- 

Not an option, unfortunately. 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S263875AbUEXXVh@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263875AbUEXXVh (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 24 May 2004 19:21:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263544AbUEXXVh
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 May 2004 19:21:37 -0400
Received: from fw.osdl.org ([65.172.181.6]:62431 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S263875AbUEXXVQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 May 2004 19:21:16 -0400
Date: Mon, 24 May 2004 16:21:15 -0700
From: Chris Wright <chrisw@osdl.org>
To: "Laughlin, Joseph V" <Joseph.V.Laughlin@boeing.com>
Cc: Herbert Poetzl <herbert@13thfloor.at>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040524162115.O22989@build.pdx.osdl.net>
References: <67B3A7DA6591BE439001F2736233351202B47E76@xch-nw-28.nw.nos.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <67B3A7DA6591BE439001F2736233351202B47E76@xch-nw-28.nw.nos.boeing.com>; from Joseph.V.Laughlin@boeing.com on Mon, May 24, 2004 at 04:04:43PM -0700
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)

Sounds like it's patched in.  And it likely doesn't require root per se,
but CAP_SYS_NICE (as the 2.6 code does).

So, you've got choices of how to disable those capability checks to do
what you want.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S264531AbUHOMei@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264531AbUHOMei (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 15 Aug 2004 08:34:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266663AbUHOMeh
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 15 Aug 2004 08:34:37 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:4101 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S264531AbUHOMeh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 15 Aug 2004 08:34:37 -0400
Date: Sun, 15 Aug 2004 13:34:32 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040815133432.A1750@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.58.0408151311340.27003@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408151311340.27003@skynet>; from airlied@linux.ie on Sun, Aug 15, 2004 at 01:19:31PM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> (it falls back if framebuffer is enabled...),

Can you explain what this means?


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267258AbUHOXlZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267258AbUHOXlZ (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 15 Aug 2004 19:41:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267253AbUHOXlZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 15 Aug 2004 19:41:25 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:35067 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267258AbUHOXlM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 15 Aug 2004 19:41:12 -0400
Date: Mon, 16 Aug 2004 00:40:43 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040815133432.A1750@infradead.org>
Message-ID: <Pine.LNX.4.58.0408160038320.9944@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> > Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> > (it falls back if framebuffer is enabled...),
>
> Can you explain what this means?
>

Probably should say PCI APIs properly, it now does enable/disable devices
and registers the DRM as owning the memory regions, does proper PCI
probing .. in cases where the fb is loaded on the card already it falls
back to the old ways (evil direct register writing.. ), this change will
stop you loading the fb driver adter the drm driver but this shouldn't be
a common case at all..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267486AbUHPJSw@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267486AbUHPJSw (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 05:18:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267490AbUHPJSw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 05:18:52 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:16901 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267486AbUHPJRg (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 05:17:36 -0400
Date: Mon, 16 Aug 2004 10:17:32 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: Christoph Hellwig <hch@infradead.org>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040816101732.A9150@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408160038320.9944@skynet>; from airlied@linux.ie on Mon, Aug 16, 2004 at 12:40:43AM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 12:40:43AM +0100, Dave Airlie wrote:
> Probably should say PCI APIs properly, it now does enable/disable devices
> and registers the DRM as owning the memory regions, does proper PCI
> probing .. in cases where the fb is loaded on the card already it falls
> back to the old ways (evil direct register writing.. ), this change will
> stop you loading the fb driver adter the drm driver but this shouldn't be
> a common case at all..

Eeek, doing different styles of probing is even worse than what you did
before.  Please revert to pci_find_device() util you havea proper common
driver ready.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267490AbUHPJb0@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267490AbUHPJb0 (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 05:31:26 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267494AbUHPJb0
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 05:31:26 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:54965 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267490AbUHPJbW (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 05:31:22 -0400
Date: Mon, 16 Aug 2004 10:30:55 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040816101732.A9150@infradead.org>
Message-ID: <Pine.LNX.4.58.0408161019040.21177@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>
> Eeek, doing different styles of probing is even worse than what you did
> before.  Please revert to pci_find_device() util you havea proper common
> driver ready.

There was nothing wrong with what we did before it just happened to work
like 2.4. we are now acting like real 2.6 drivers, which we need to do for
sysfs and hotplug to work, Jon Smirl is working on a proper minor device
support (like USB does I think)... we need to get this work done before we
can have proper common drivers and I don't want to do all this work in
hiding and then have it refused because we told no-one,

The DRM will flux a lot over the next while (while we get this common
drm/fb stuff together) and as long as we can keep the changes from
actually breaking it I think people should be able to live with it ...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267495AbUHPJuW@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267495AbUHPJuW (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 05:50:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267501AbUHPJuV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 05:50:21 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:19973 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267495AbUHPJuS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 05:50:18 -0400
Date: Mon, 16 Aug 2004 10:50:14 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: Christoph Hellwig <hch@infradead.org>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040816105014.A9367@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org> <Pine.LNX.4.58.0408161019040.21177@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408161019040.21177@skynet>; from airlied@linux.ie on Mon, Aug 16, 2004 at 10:30:55AM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 10:30:55AM +0100, Dave Airlie wrote:
> >
> > Eeek, doing different styles of probing is even worse than what you did
> > before.  Please revert to pci_find_device() util you havea proper common
> > driver ready.
> 
> There was nothing wrong with what we did before it just happened to work
> like 2.4. we are now acting like real 2.6 drivers,

no, now you're acting like an even more broken driver, preventing a fbdev
driver to be loaded afterwards and doing all kinds of funny things.  Please
revert to the old method until you have a common pci_driver for fbdev and dri.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267507AbUHPK3v@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267507AbUHPK3v (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 06:29:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267514AbUHPK3v
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 06:29:51 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:61628 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267507AbUHPK3t (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 06:29:49 -0400
Date: Mon, 16 Aug 2004 11:29:48 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040816105014.A9367@infradead.org>
Message-ID: <Pine.LNX.4.58.0408161101050.21177@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
 <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


>
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things.  Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
>

the options we have are
1) move the DRM to be a real PCI driver now - stop fb from working on same
card

2) move the DRM to act like a real PCI driver when fb isn't loaded, when
we merge we rip the code out..

the other option is not going to happen unless Linus/Andrew/Alan tell us
to go away do it that away and will then unconditionally merge a
mega-patch when I'm finished - you can't have it both ways we fix things
step-by-step or we leave it as is and nobody fixes it, so Christoph I
repsect your opinion but unless you care about this enough to do the work
on it, the way we are going seems to be the best way to avoid breaking
things and I'm leaving the decision on whether to merge this stuff or not
to Linus/Andrew - btw in case anyone wants to look the patch is whats at:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/broken-out/bk-drm.patch

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267514AbUHPKiy@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267514AbUHPKiy (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 06:38:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267516AbUHPKiy
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 06:38:54 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:21509 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267514AbUHPKiw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 06:38:52 -0400
Date: Mon, 16 Aug 2004 11:38:48 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: Christoph Hellwig <hch@infradead.org>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040816113848.A9683@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org> <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org> <Pine.LNX.4.58.0408161101050.21177@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408161101050.21177@skynet>; from airlied@linux.ie on Mon, Aug 16, 2004 at 11:29:48AM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 11:29:48AM +0100, Dave Airlie wrote:
> 1) move the DRM to be a real PCI driver now - stop fb from working on same
> card
> 
> 2) move the DRM to act like a real PCI driver when fb isn't loaded, when
> we merge we rip the code out..

3) stop making broken changes.

	You do stop fb from beeing loaded after drm
and thus break perfectly working setups during stable series.  And you
introduce indeterministic behaviour, and although I haven't looked at the
code because unlike every guideline tells you you didn't post it to do the
list, probably horribly broken code.

If you want pci_driver semantics - and apparently you do - move fbdev
and drm into a common driver or introduce a stub.  This was discussed to
death and all kinds of list and Kernel Summit and now please follow what
was agreed on instead of introducing subtile hacks.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267522AbUHPLCT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267522AbUHPLCT (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 07:02:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267528AbUHPLCT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 07:02:19 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:23233 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267522AbUHPLCQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 07:02:16 -0400
Date: Mon, 16 Aug 2004 12:02:15 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040816113848.A9683@infradead.org>
Message-ID: <Pine.LNX.4.58.0408161142490.21177@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
 <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org>
 <Pine.LNX.4.58.0408161101050.21177@skynet> <20040816113848.A9683@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


>
> 3) stop making broken changes.

The current system is broken in way more subtle ways...

> 	You do stop fb from beeing loaded after drm
> and thus break perfectly working setups during stable series.  And you

I doubt anyone has a system that does it and they should have a broken one
if they do it.. drm has also said you should load fb before it.. and
having both fb and drm loaded on the same hardware is a hack anyways..

> introduce indeterministic behaviour, and although I haven't looked at the
> code because unlike every guideline tells you you didn't post it to do the
> list, probably horribly broken code.

I just did post it, it's been in the DRM CVS tree for 3-6 mths now, it's
been in -mm for 1.5 mths, I've followed what Andrew and Linus told me to
do to get the DRM maintained... the link I posted in the last mail to the
broken out patch in the -mm tree, the only file to change is really
drm_drv.h and some bits in drm_stub.h... the current code is we have
discovered horribly broken in a lot of cases.. I've gotten nothing back to
say this code is any worse....

> If you want pci_driver semantics - and apparently you do - move fbdev
> and drm into a common driver or introduce a stub.  This was discussed to
> death and all kinds of list and Kernel Summit and now please follow what
> was agreed on instead of introducing subtile hacks.

Yes and that is the final goal but you are dodging the point we cannot
jump to a fully finished state in one simple transition, it is great to
hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
it must be simple, well its not and we are taking the route that should
affect the least people, I'm majorly involved in the discussion and I was
the one to agree to carry out the maintenance paths between DRM and LK,
this code is needed for us to move forward with the merged drivers - if
Linus/Andrew decide not to merge it I'll go back to the DRM team and it'll
be reworked until they do accept it, but we have to stop the fb from
loading after the DRM at some stage and it may as well be earlier.. (if
2.7 was going to happen I'd wait but kernel development seems to be
changing...)

You seem to want us to go down the finished unmergeable mega-patch road
to avoid breaking something that is broken and might work, the benefits
don't outweight the costs.. so it makes no sense..

Again if Linus/Andrew bounce this we will have to rework it but something
like this has to go in at some stage...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267538AbUHPLIW@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267538AbUHPLIW (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 07:08:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267536AbUHPLIW
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 07:08:22 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:22277 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267531AbUHPLII (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 07:08:08 -0400
Date: Mon, 16 Aug 2004 12:08:01 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20040816120801.A9862@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org> <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org> <Pine.LNX.4.58.0408161101050.21177@skynet> <20040816113848.A9683@infradead.org> <Pine.LNX.4.58.0408161142490.21177@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408161142490.21177@skynet>; from airlied@linux.ie on Mon, Aug 16, 2004 at 12:02:15PM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 12:02:15PM +0100, Dave Airlie wrote:
> > 	You do stop fb from beeing loaded after drm
> > and thus break perfectly working setups during stable series.  And you
> 
> I doubt anyone has a system that does it and they should have a broken one
> if they do it.. drm has also said you should load fb before it.. and
> having both fb and drm loaded on the same hardware is a hack anyways..

So fix it properly instead of making it even more broken.

> Yes and that is the final goal but you are dodging the point we cannot
> jump to a fully finished state in one simple transition, it is great to
> hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> it must be simple, well its not and we are taking the route that should

It _is+ simple.  Look at drivers/message/fusion/ for a driver doing multiple
protocol on a single pci_driver.  I don't demand full-blown memory management
integration or anything pother fancy.  Just get your crap sorted out.

ou could propably have done a prototype in the time you wasted arguing here.

> You seem to want us to go down the finished unmergeable mega-patch road
> to avoid breaking something that is broken and might work, the benefits
> don't outweight the costs.. so it makes no sense..

I want you a) to back out this particular broken change in your current
mega-patch.  and b) submit small reviewable changes in the future, as every
other driver maintainer does.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267553AbUHPLrq@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267553AbUHPLrq (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 07:47:46 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267554AbUHPLrq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 07:47:46 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:29382 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267553AbUHPLrm (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 07:47:42 -0400
Date: Mon, 16 Aug 2004 12:47:16 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040816120801.A9862@infradead.org>
Message-ID: <Pine.LNX.4.58.0408161218520.32584@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
 <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org>
 <Pine.LNX.4.58.0408161101050.21177@skynet> <20040816113848.A9683@infradead.org>
 <Pine.LNX.4.58.0408161142490.21177@skynet> <20040816120801.A9862@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> > Yes and that is the final goal but you are dodging the point we cannot
> > jump to a fully finished state in one simple transition, it is great to
> > hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> > it must be simple, well its not and we are taking the route that should
>
> It _is+ simple.  Look at drivers/message/fusion/ for a driver doing multiple
> protocol on a single pci_driver.  I don't demand full-blown memory management
> integration or anything pother fancy.  Just get your crap sorted out.
>
> ou could propably have done a prototype in the time you wasted arguing here.

we could write one quick enough for one card but now make it work on
combinations of mach64/i810/radeon/r128/i830/i915/mga cards and tested so
that it doesn't break current setups, its just not going to happen, this
change doesn't break near as many setups (I'd be surprised if it broke any
real world setups at all...) I don't have the hardware to test this on all
those cards, the hope is to get the DRM into a state that we can start
proving the shared idea on one card.. it will also make changes to fb
drivers which I'm not comfortable with doing and will cause more hassles..

> I want you a) to back out this particular broken change in your current
> mega-patch.  and b) submit small reviewable changes in the future, as every
> other driver maintainer does.

I'm considering your argument and have taken it on-board, I await Linus's
decision for now, I'll start looking into the info you've given me and
I'll talk to the DRM people actually doing the work (not one line of this
is orignally from me!!..)

All DRM changes are available in small chunks in DRM CVS and DRM bk trees,
the -mm tree picks up the DRM changes and I fix the bugs that come up in
the -mm tree and then I submit the bk tree to Linus, I thought this was
how kernel development worked these days,

The patch you are against is
http://drm.bkbits.net:8080/drm-2.6/patch@1.1784.4.4?nav=index.html|tags|ChangeSet@1.1722.154.18..|cset@1.1784.4.4

with a couple of bugfixes on top of it from testing in -mm.. if I'm
missing the kernel development process somehow please inform me.. I'm new
to this maintainer job and the drm hasn't been maintained in years so I'm
not starting from a good place...

Thanks,
Dave.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267563AbUHPMPK@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267563AbUHPMPK (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 08:15:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267571AbUHPMPK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 08:15:10 -0400
Received: from the-village.bc.nu ([81.2.110.252]:52451 "EHLO
	localhost.localdomain") by vger.kernel.org with ESMTP
	id S267563AbUHPMPD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 08:15:03 -0400
Subject: Re: your mail
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <20040816120801.A9862@infradead.org>
References: <Pine.LNX.4.58.0408151311340.27003@skynet>
	 <20040815133432.A1750@infradead.org>
	 <Pine.LNX.4.58.0408160038320.9944@skynet>
	 <20040816101732.A9150@infradead.org>
	 <Pine.LNX.4.58.0408161019040.21177@skynet>
	 <20040816105014.A9367@infradead.org>
	 <Pine.LNX.4.58.0408161101050.21177@skynet>
	 <20040816113848.A9683@infradead.org>
	 <Pine.LNX.4.58.0408161142490.21177@skynet>
	 <20040816120801.A9862@infradead.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1092654751.20517.20.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Mon, 16 Aug 2004 12:12:33 +0100
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Llu, 2004-08-16 at 12:08, Christoph Hellwig wrote:
> I want you a) to back out this particular broken change in your current
> mega-patch.  and b) submit small reviewable changes in the future, as every
> other driver maintainer does.

DRI is done as small reviewable changes. If you want to be involved then
follow the DRI list too or ask for the entire list to be gated to
linux-kernel for your pleasure...


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S265978AbUHPMOm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S265978AbUHPMOm (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 08:14:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267575AbUHPMOm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 08:14:42 -0400
Received: from the-village.bc.nu ([81.2.110.252]:50659 "EHLO
	localhost.localdomain") by vger.kernel.org with ESMTP
	id S265978AbUHPMOe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 08:14:34 -0400
Subject: Re: your mail
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Airlie <airlied@linux.ie>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <20040816105014.A9367@infradead.org>
References: <Pine.LNX.4.58.0408151311340.27003@skynet>
	 <20040815133432.A1750@infradead.org>
	 <Pine.LNX.4.58.0408160038320.9944@skynet>
	 <20040816101732.A9150@infradead.org>
	 <Pine.LNX.4.58.0408161019040.21177@skynet>
	 <20040816105014.A9367@infradead.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1092654719.20523.18.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Mon, 16 Aug 2004 12:12:00 +0100
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things.  Please
> revert to the old method until you have a common pci_driver for fbdev and dri.

fbdev and DRI are not functional together in the general case. They
sometimes happen to work by luck. fbdev and X for that matter are
generally incompatible except unaccelerated.



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267571AbUHPMVU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267571AbUHPMVU (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 08:21:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267584AbUHPMU4
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 08:20:56 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:26117 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267576AbUHPMU2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 08:20:28 -0400
Date: Mon, 16 Aug 2004 13:20:22 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>, Dave Airlie <airlied@linux.ie>,
       torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20040816132022.A10567@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>, Dave Airlie <airlied@linux.ie>,
	torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org> <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org> <1092654719.20523.18.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <1092654719.20523.18.camel@localhost.localdomain>; from alan@lxorguk.ukuu.org.uk on Mon, Aug 16, 2004 at 12:12:00PM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 12:12:00PM +0100, Alan Cox wrote:
> On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> > no, now you're acting like an even more broken driver, preventing a fbdev
> > driver to be loaded afterwards and doing all kinds of funny things.  Please
> > revert to the old method until you have a common pci_driver for fbdev and dri.
> 
> fbdev and DRI are not functional together in the general case. They
> sometimes happen to work by luck. fbdev and X for that matter are
> generally incompatible except unaccelerated.

Works fine on all my pmacs here.  In fact X works only on fbdev for
full features.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267606AbUHPMZU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267606AbUHPMZU (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 08:25:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267626AbUHPMZU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 08:25:20 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:15819 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S267606AbUHPMYh (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 08:24:37 -0400
Date: Mon, 16 Aug 2004 13:24:30 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20040816132022.A10567@infradead.org>
Message-ID: <Pine.LNX.4.58.0408161323300.32584@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
 <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org>
 <1092654719.20523.18.camel@localhost.localdomain> <20040816132022.A10567@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>
> Works fine on all my pmacs here.  In fact X works only on fbdev for
> full features.

I think Alan would classify that as luck rathar than design... and I would
tend to agree, does it work if you load the driver modules in any order?
or do you always to fb then drm? or the other way around?

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267575AbUHPMhd@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267575AbUHPMhd (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 08:37:33 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267584AbUHPMhc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 08:37:32 -0400
Received: from imladris.demon.co.uk ([193.237.130.41]:27141 "EHLO
	phoenix.infradead.org") by vger.kernel.org with ESMTP
	id S267575AbUHPMhb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 08:37:31 -0400
Date: Mon, 16 Aug 2004 13:37:28 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: Christoph Hellwig <hch@infradead.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
       torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20040816133728.A10686@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Dave Airlie <airlied@linux.ie>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org> <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org> <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org> <1092654719.20523.18.camel@localhost.localdomain> <20040816132022.A10567@infradead.org> <Pine.LNX.4.58.0408161323300.32584@skynet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.58.0408161323300.32584@skynet>; from airlied@linux.ie on Mon, Aug 16, 2004 at 01:24:30PM +0100
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by phoenix.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 16, 2004 at 01:24:30PM +0100, Dave Airlie wrote:
> >
> > Works fine on all my pmacs here.  In fact X works only on fbdev for
> > full features.
> 
> I think Alan would classify that as luck rathar than design... and I would

All the fbdev handling code in X is also an accident?

Really, why do you even push for this change if the better fix isn't that
far away.  Send the i915 driver and the other misc cleanups to Linus now
and get a proper graphics stub driver done, it's not that much work.  I'll
hack up the fbdev side once I'll get a little time, but the drm code is
far to disgusting to touch, sorry.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S267806AbUHPPsS@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S267806AbUHPPsS (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 11:48:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267702AbUHPPpS
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 11:45:18 -0400
Received: from web14925.mail.yahoo.com ([216.136.225.11]:5822 "HELO
	web14925.mail.yahoo.com") by vger.kernel.org with SMTP
	id S267809AbUHPPmp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 11:42:45 -0400
Message-ID: <20040816154240.54747.qmail@web14925.mail.yahoo.com>
Date: Mon, 16 Aug 2004 08:42:40 -0700 (PDT)
From: Jon Smirl <jonsmirl@yahoo.com>
Subject: Re: your mail
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@osdl.org, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, Dave Airlie <airlied@linux.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Graphics drivers in the kernel are broken. The kernel was never
designed to have two device drivers trying to control the same piece of
hardware. 
I have posted a long list of 25 points that we are working towards to
unify things. http://lkml.org/lkml/2004/8/2/111 The PCI ROM patch that
has been posted recently addresses the first one.

In the meanwhile we have to transition somehow between what we have and
where we are going. Since fbdev has taken the path to pretend that DRM
doesn't exist DRM has to go through a lot of trouble to work when fbdev
is in the system. DRM also has to work when fbdev is not in the system.

DRM is being reworked into a first class driver with full support for
2.6 and hotplug. Part of being a first class driver means that DRM has
to register itself with the kernel like a real driver and claim all of
it's resources. I'm also fixing the driver to use 2.6 module parameters
and to support dynamic assignment of minors. Sysfs support is in the
patch being discussed.

But DRM still has to live with existing fbdev drivers. The same DRM
code is used in 2.4 and 2.6 so existing fbdev drivers are not going
away anytime soon. When DRM detects a fbdev it will revert back into
stealth mode where is attaches itself to the hardware without telling
the kernel that it is doing so. DRM can not use stealth mode when
running without fbdev present since it will mess up hotplug by not
marking the resources in use.

I don't believe the ordering between fbdev and DRM is an issue. If you
are using fbdev you likely have it compiled in. In that case fbdev
always loads first and DRM second. In the non-ppc world, most of us
have x86 boxes which don't use fbdev. In those machines DRM needs to be
a first class driver. In the real world I don't know anyone other than
a developer who would load DRM first and then fbdev. If this is a
problem you will need to fixed fbdev to fall back into stealth mode
like DRM does.

I would like to encourage you to work towards the points on the above
referenced list. It has been widely distributed and commented on. It
has been posted to lkml, dri-dev, fb-dev and xorg lists and discussed
at OLS. 

Sorry, but I can't add an In-Reply-To header in the middle of thread on
yahoo. cc me on a reply to the main thread so that I will pick up the header.

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S266460AbUHPXdj@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S266460AbUHPXdj (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 19:33:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266461AbUHPXdj
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 19:33:39 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:40853 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S266460AbUHPXdg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 19:33:36 -0400
Date: Tue, 17 Aug 2004 00:33:35 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20040816133728.A10686@infradead.org>
Message-ID: <Pine.LNX.4.58.0408170024570.26072@skynet>
References: <Pine.LNX.4.58.0408151311340.27003@skynet> <20040815133432.A1750@infradead.org>
 <Pine.LNX.4.58.0408160038320.9944@skynet> <20040816101732.A9150@infradead.org>
 <Pine.LNX.4.58.0408161019040.21177@skynet> <20040816105014.A9367@infradead.org>
 <1092654719.20523.18.camel@localhost.localdomain> <20040816132022.A10567@infradead.org>
 <Pine.LNX.4.58.0408161323300.32584@skynet> <20040816133728.A10686@infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>
> All the fbdev handling code in X is also an accident?

I've no idea I've nothing to do with X... but the fact that graphics work
at all with fb/drm/X is by no fault of any design it is pure hack ...

> Really, why do you even push for this change if the better fix isn't that
> far away.  Send the i915 driver and the other misc cleanups to Linus now
> and get a proper graphics stub driver done, it's not that much work.  I'll
> hack up the fbdev side once I'll get a little time, but the drm code is
> far to disgusting to touch, sorry.

It means writing 6 or 7 stub drivers, for cards we don't have, it means
making PCI probing different for some fbdev drivers and some DRM drivers
(e.g. the i915 doesn't have a framebuffer driver in 2.6 so do I write a
stub on the chance that someone writes an fb driver for it? -  why do this
when the DRM will start encompassing the fb soon..) it is a lot of work
that we intend throwing away, the final solution is not to merge DRM/fb
via a stub, it is to create a single driver for each card, what happens
when the DRM starts doing memory management and 2d stuff.. we won't want
fb to be able to load anymore as it will break the DRM...I see Jon Smirl
has found the thread, please discuss with him as he was the one doing all
the legwork at the kernel summit...

again this doesn't break any real setups, it is the path of least
resistance as it doesn't affect fb drivers, why should DRM be a second
class citizen, when it is clearly going to have to be a first class 2.6
driver to do its job... if you can find someone with a real world setup
that this breaks I'll consider it a really bad idea... but I think Jon has
made his point far better than I...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S268026AbUHPXzm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S268026AbUHPXzm (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 16 Aug 2004 19:55:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268030AbUHPXzm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 16 Aug 2004 19:55:42 -0400
Received: from holly.csn.ul.ie ([136.201.105.4]:20887 "EHLO holly.csn.ul.ie")
	by vger.kernel.org with ESMTP id S268026AbUHPXzj (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Aug 2004 19:55:39 -0400
Date: Tue, 17 Aug 2004 00:55:38 +0100 (IST)
From: Dave Airlie <airlied@linux.ie>
X-X-Sender: airlied@skynet
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: Christoph Hellwig <hch@infradead.org>, torvalds@osdl.org,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20040816154240.54747.qmail@web14925.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0408170052571.26072@skynet>
References: <20040816154240.54747.qmail@web14925.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> But DRM still has to live with existing fbdev drivers. The same DRM
> code is used in 2.4 and 2.6 so existing fbdev drivers are not going
> away anytime soon. When DRM detects a fbdev it will revert back into
> stealth mode where is attaches itself to the hardware without telling
> the kernel that it is doing so. DRM can not use stealth mode when
> running without fbdev present since it will mess up hotplug by not
> marking the resources in use.
>
> I don't believe the ordering between fbdev and DRM is an issue. If you
> are using fbdev you likely have it compiled in. In that case fbdev
> always loads first and DRM second. In the non-ppc world, most of us
> have x86 boxes which don't use fbdev. In those machines DRM needs to be
> a first class driver. In the real world I don't know anyone other than
> a developer who would load DRM first and then fbdev. If this is a
> problem you will need to fixed fbdev to fall back into stealth mode
> like DRM does.

This is a good point, we are being forced into stealth mode by the fb
driver if they want to load after us they should respsect us and do the
same, (nope this isn't an us and them, DRM vs fb - I think we have a
solution and are heading the correct direction)...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261602AbUISSQI@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261602AbUISSQI (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 19 Sep 2004 14:16:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261711AbUISSQI
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 19 Sep 2004 14:16:08 -0400
Received: from mail.dif.dk ([193.138.115.101]:61075 "EHLO mail.dif.dk")
	by vger.kernel.org with ESMTP id S261602AbUISSQD (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 19 Sep 2004 14:16:03 -0400
Date: Sun, 19 Sep 2004 20:22:41 +0200 (CEST)
From: Jesper Juhl <juhl-lkml@dif.dk>
To: plt@taylorassociate.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <1095596968.414d7ba88efc1@webmail.taylorassociate.com>
Message-ID: <Pine.LNX.4.61.0409191739140.2758@dragon.hygekrogen.localhost>
References: <1095596968.414d7ba88efc1@webmail.taylorassociate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 19 Sep 2004 plt@taylorassociate.com wrote:

> Question: Are you guys going to work on please cleaning up some of the errors in
> the code so we can get please get a more clean compile?
> 
I think it's safe to say that there is an ongoing effort to do that.

Some more strict typechecking has recently been introduced (read more 
here: http://kerneltrap.org/node/view/3848 ) and this currently cause a 
lot of compiler warnings that have yet to be cleaned, but that will happen 
in time - faster if you lend a hand.

> 
> drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
> 
This is due to the fact that the code using that variable is currently 
within an  #if 0  block. I am not familiar with the mtd code, but the 
comment in there has this to say :

#if 0 /* Some people seem to have devices without ECC or erase marks
         on the Media Header blocks. There are enough other sanity
         checks in here that we can probably do without it.
      */

...

#endif

So it would seem that this bit of code could be on its way out. I'd assume 
that once it goes (if it does) that the variable will then be removed as 
well.


Ohh and btw, if you want people to pay attention to your emails you should 
try adding a descriptive Subject:  :)


--
Jesper Juhl


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262904AbVBCBOH@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262904AbVBCBOH (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 2 Feb 2005 20:14:07 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262895AbVBCBM6
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 2 Feb 2005 20:12:58 -0500
Received: from multivac.one-eyed-alien.net ([64.169.228.101]:39849 "EHLO
	multivac.one-eyed-alien.net") by vger.kernel.org with ESMTP
	id S262850AbVBCBMd (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 2 Feb 2005 20:12:33 -0500
Date: Wed, 2 Feb 2005 17:12:24 -0800
From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: Aleksey Gorelov <Aleksey_Gorelov@Phoenix.com>
Cc: stern@rowland.harvard.edu, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20050203011224.GA29748@one-eyed-alien.net>
Mail-Followup-To: Aleksey Gorelov <Aleksey_Gorelov@Phoenix.com>,
	stern@rowland.harvard.edu, linux-kernel@vger.kernel.org
References: <5F106036E3D97448B673ED7AA8B2B6B301B3CD73@scl-exch2k.phoenix.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <5F106036E3D97448B673ED7AA8B2B6B301B3CD73@scl-exch2k.phoenix.com>
User-Agent: Mutt/1.4.1i
Organization: One Eyed Alien Networks
X-Copyright: (C) 2005 Matthew Dharm, all rights reserved.
X-Message-Flag: Get a real e-mail client.  http://www.mutt.org/
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

It's basically just like the code says.

A lot of devices choke if you access them too quickly after enumeration.
The 5 second delay seems to be enough for most devices.  But we made it
adjustable exactly for people like you.

Matt

On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote:
> Hi Matt, Alan,=20
>=20
>   Could you please tell me (link would do) why it makes default
> delay_use=3D5=20
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
>=20
> It makes USB boot really painfull and slow :(
>=20
>   I understand there should be a good reason for it. I've tried to find
> an answer in=20
> archives, without much success though.
>=20
> Thanks,
> Aleks.

--=20
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=
net=20
Maintainer, Linux USB Mass Storage Driver

Now payink attention, please.  This is mouse.  Click-click. Easy to=20
use, da? Now you try...
					-- Pitr to Miranda
User Friendly, 10/11/1998

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCAXp4IjReC7bSPZARAqplAJ9WD9TRlryVc1ikb8L4QZFsq+ezyQCgrnAw
qakC8xzTroMWe/o9zuY30Q4=
=kQBj
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262549AbVBCQD6@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262549AbVBCQD6 (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 3 Feb 2005 11:03:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262523AbVBCQD5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 3 Feb 2005 11:03:57 -0500
Received: from ida.rowland.org ([192.131.102.52]:6660 "HELO ida.rowland.org")
	by vger.kernel.org with SMTP id S263720AbVBCQDb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Feb 2005 11:03:31 -0500
Date: Thu, 3 Feb 2005 11:03:29 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@ida.rowland.org
To: Aleksey Gorelov <Aleksey_Gorelov@Phoenix.com>
cc: mdharm-usb@one-eyed-alien.net, <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <5F106036E3D97448B673ED7AA8B2B6B301B3CD73@scl-exch2k.phoenix.com>
Message-ID: <Pine.LNX.4.44L0.0502031056560.1125-100000@ida.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2 Feb 2005, Aleksey Gorelov wrote:

> Hi Matt, Alan, 
> 
>   Could you please tell me (link would do) why it makes default
> delay_use=5 
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
> 
> It makes USB boot really painfull and slow :(
> 
>   I understand there should be a good reason for it. I've tried to find
> an answer in 
> archives, without much success though.

Lots of devices don't need that delay, but enough of them do that we 
decided to add it.  The value of 5 seconds was more or less arbitrary; it 
was long enough for every device we could test and it didn't seem _too_ 
long.  Maybe 1 second would be long enough -- we just didn't know so we 
were conservative.

Alan Stern


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261858AbVFPXcZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261858AbVFPXcZ (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 16 Jun 2005 19:32:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261860AbVFPXcZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 16 Jun 2005 19:32:25 -0400
Received: from ylpvm43-ext.prodigy.net ([207.115.57.74]:55732 "EHLO
	ylpvm43.prodigy.net") by vger.kernel.org with ESMTP id S261858AbVFPXcP
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 16 Jun 2005 19:32:15 -0400
X-ORBL: [63.202.173.158]
Date: Thu, 16 Jun 2005 16:32:07 -0700
From: Chris Wedgwood <cw@f00f.org>
To: trmcneal@comcast.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <165572.73a4e5686a7ab70d16f3e50cdfb77252.ANY@taniwha.stupidest.org>
References: <061620052308.15335.42B2066C000DD5E200003BE72205886172040E0A020C039D9B@comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <061620052308.15335.42B2066C000DD5E200003BE72205886172040E0A020C039D9B@comcast.net>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:

> > I've been working with some tcp network test programs that have
> > multiple clients opening nonblocking sockets to a single server
> > port, sending a short message, and then closing the socket,
> > 100,000 times.  Since the socket is non-blocking, it generally
> > tries to connect and then does a poll since the socket is busy.
> > The test fails if the poll times out in 10 seconds.  It fails
> > consistently on Linux servers but succeeds on Solaris servers; the
> > client is a non-issue unless its loopback on the Linux server.

where is the code for this?  are you sure you're not overflowing the
listen backlog somewhere?  that would show up in some cases but not
all depending on latencies and local scheduler behavior

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261886AbVFQBnx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261886AbVFQBnx (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 16 Jun 2005 21:43:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261888AbVFQBnx
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 16 Jun 2005 21:43:53 -0400
Received: from sccrmhc14.comcast.net ([204.127.202.59]:54739 "EHLO
	sccrmhc14.comcast.net") by vger.kernel.org with ESMTP
	id S261886AbVFQBnv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 16 Jun 2005 21:43:51 -0400
Message-ID: <42B22B75.7020509@comcast.net>
Date: Thu, 16 Jun 2005 18:46:29 -0700
From: Tom McNeal <trmcneal@comcast.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Chris Wedgwood <cw@f00f.org>
CC: linux-kernel@vger.kernel.org
Subject: Re: your mail
References: <061620052308.15335.42B2066C000DD5E200003BE72205886172040E0A020C039D9B@comcast.net> <165572.73a4e5686a7ab70d16f3e50cdfb77252.ANY@taniwha.stupidest.org>
In-Reply-To: <165572.73a4e5686a7ab70d16f3e50cdfb77252.ANY@taniwha.stupidest.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

I'll look at that.  This occurs on all Linux platforms, including a generic
2.4.31 I downloaded from kernel.org. The user test is trivial, just doing
the nonblocking connect, the poll, the send, and then the close, in that loop.

Tom

Chris Wedgwood wrote:
> On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:
> 
> 
>>>I've been working with some tcp network test programs that have
>>>multiple clients opening nonblocking sockets to a single server
>>>port, sending a short message, and then closing the socket,
>>>100,000 times.  Since the socket is non-blocking, it generally
>>>tries to connect and then does a poll since the socket is busy.
>>>The test fails if the poll times out in 10 seconds.  It fails
>>>consistently on Linux servers but succeeds on Solaris servers; the
>>>client is a non-issue unless its loopback on the Linux server.
> 
> 
> where is the code for this?  are you sure you're not overflowing the
> listen backlog somewhere?  that would show up in some cases but not
> all depending on latencies and local scheduler behavior
> 

-- 
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
Email: trmcneal@comcast.net

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1750765AbVKZALL@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750765AbVKZALL (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 25 Nov 2005 19:11:11 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751037AbVKZALK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 25 Nov 2005 19:11:10 -0500
Received: from gold.veritas.com ([143.127.12.110]:38474 "EHLO gold.veritas.com")
	by vger.kernel.org with ESMTP id S1750765AbVKZALK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Nov 2005 19:11:10 -0500
Date: Sat, 26 Nov 2005 00:11:10 +0000 (GMT)
From: Hugh Dickins <hugh@veritas.com>
X-X-Sender: hugh@goblin.wat.veritas.com
To: root <root@txiringo.dyndns.org>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <20051125220620.968F72404DC7@txiringo>
Message-ID: <Pine.LNX.4.61.0511260009080.13981@goblin.wat.veritas.com>
References: <20051125220620.968F72404DC7@txiringo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 26 Nov 2005 00:11:05.0600 (UTC) FILETIME=[E4C4C000:01C5F21D]
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 25 Nov 2005, root wrote:

> Nov 25 21:59:24 txiringo kernel: [17182458.504000] program ddcprobe
> is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory, which
> is deprecated. Please report this to linux-kernel@vger.kernel.org

Thanks for the report: now fixed, please upgrade to 2.6.15-rc2-git3 or later.

Hugh

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S932206AbXBEMge@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932206AbXBEMge (ORCPT <rfc822;w@1wt.eu>);
	Mon, 5 Feb 2007 07:36:34 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932113AbXBEMge
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 5 Feb 2007 07:36:34 -0500
Received: from outbound-blu.frontbridge.com ([65.55.251.16]:40656 "EHLO
	outbound8-blu-R.bigfish.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S932206AbXBEMgd (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 5 Feb 2007 07:36:33 -0500
X-BigFish: VP
X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF
Date: Mon, 5 Feb 2007 13:36:11 +0100
From: "Joerg Roedel" <joerg.roedel@amd.com>
To: logic@thinknet.ro
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20070205123611.GI8804@amd.com>
References: <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
MIME-Version: 1.0
In-Reply-To: <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
User-Agent: mutt-ng/devel-r804 (Linux)
X-OriginalArrivalTime: 05 Feb 2007 12:36:14.0453 (UTC)
 FILETIME=[396D5250:01C74922]
X-WSS-ID: 69D9FB421WC6056033-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 05, 2007 at 05:41:29PM +0200, logic@thinknet.ro wrote:
> Good morning,
> 
> I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
> Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
> output of the hang:

Hmm, this seems to be the same issue as in [1] and [2]. A page that is
assumed to belong to the slab but is not longer marked as a slab page.
Could this be a bug in the memory management?

Joerg

[1] http://lkml.org/lkml/2007/2/4/77
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406477

-- 
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S932582AbXBEOB0@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932582AbXBEOB0 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 5 Feb 2007 09:01:26 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932585AbXBEOB0
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 5 Feb 2007 09:01:26 -0500
Received: from ug-out-1314.google.com ([66.249.92.175]:15608 "EHLO
	ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932582AbXBEOBZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 5 Feb 2007 09:01:25 -0500
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=kjG6QnSMKGwbcxfK2sBBXCTwdDSjiIXZIYrkzzyyYaaVHehSWPgUCy+WusU1Y/7jQfNiBi8wreuHnJSfevEl2en4e7VUXNfwm49h74cXDJ1Do1c6G1/nDcNwl70kSL/whfxtOJ4pXmH7GZexernn6EtrI1+DOX+riGsEvId0Mws=
Message-ID: <84144f020702050601ve2e4746oebd774af9c487b63@mail.gmail.com>
Date: Mon, 5 Feb 2007 16:01:23 +0200
From: "Pekka Enberg" <penberg@cs.helsinki.fi>
To: "Joerg Roedel" <joerg.roedel@amd.com>
Subject: Re: your mail
Cc: logic@thinknet.ro, linux-kernel@vger.kernel.org
In-Reply-To: <20070205123611.GI8804@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
	 <20070205123611.GI8804@amd.com>
X-Google-Sender-Auth: 07b8b09f00f18033
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Joerg,

On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> assumed to belong to the slab but is not longer marked as a slab page.
> Could this be a bug in the memory management?

The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
kmem_cache_free() so I am guessing the caller is simply broken. Note
that kernels prior to 2.6.18 would quietly corrupt the slab unless
CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
noticed before.

                               Pekka

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1751957AbXBFJvA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751957AbXBFJvA (ORCPT <rfc822;w@1wt.eu>);
	Tue, 6 Feb 2007 04:51:00 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751967AbXBFJvA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 6 Feb 2007 04:51:00 -0500
Received: from outbound-fra.frontbridge.com ([62.209.45.174]:64296 "EHLO
	outbound4-fra-R.bigfish.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751957AbXBFJu7 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 6 Feb 2007 04:50:59 -0500
X-BigFish: VP
X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89
Date: Tue, 6 Feb 2007 10:41:08 +0100
From: "Joerg Roedel" <joerg.roedel@amd.com>
To: "Pekka Enberg" <penberg@cs.helsinki.fi>
cc: logic@thinknet.ro, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20070206094108.GC18017@amd.com>
References: <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
 <20070205123611.GI8804@amd.com>
 <84144f020702050601ve2e4746oebd774af9c487b63@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <84144f020702050601ve2e4746oebd774af9c487b63@mail.gmail.com>
User-Agent: mutt-ng/devel-r804 (Linux)
X-OriginalArrivalTime: 06 Feb 2007 09:41:12.0133 (UTC)
 FILETIME=[EFF83750:01C749D2]
X-WSS-ID: 69D690A62MC7212473-10-01
Content-Type: text/plain;
 charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 05, 2007 at 04:01:23PM +0200, Pekka Enberg wrote:
> Hi Joerg,
> 
> On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> >Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> >assumed to belong to the slab but is not longer marked as a slab page.
> >Could this be a bug in the memory management?
> 
> The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
> kmem_cache_free() so I am guessing the caller is simply broken. Note
> that kernels prior to 2.6.18 would quietly corrupt the slab unless
> CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
> noticed before.

Ok. I was not aware of that. Thanks for clarification.

Joerg

-- 
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S934342AbXC2VmS@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934342AbXC2VmS (ORCPT <rfc822;w@1wt.eu>);
	Thu, 29 Mar 2007 17:42:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934343AbXC2VmS
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 29 Mar 2007 17:42:18 -0400
Received: from tmailer.gwdg.de ([134.76.10.23]:58589 "EHLO tmailer.gwdg.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S934342AbXC2VmR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 29 Mar 2007 17:42:17 -0400
Date: Thu, 29 Mar 2007 23:42:17 +0200 (MEST)
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <e8f45b9e0703291439q505c6a06re003e91484a20354@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0703292341370.31834@yvahk01.tjqt.qr>
References: <e8f45b9e0703291439q505c6a06re003e91484a20354@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Report: Content analysis: 0.0 points, 6.0 required
	_SUMMARY_
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


>
> unsubscribe linux-kernel ..

I wonder why people can't send their unsubscribe message to the same 
address they sent their subscribe message to.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S934347AbXC2VrE@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934347AbXC2VrE (ORCPT <rfc822;w@1wt.eu>);
	Thu, 29 Mar 2007 17:47:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934354AbXC2VrD
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 29 Mar 2007 17:47:03 -0400
Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:55385
	"EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK)
	by vger.kernel.org with ESMTP id S934355AbXC2VrB (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 29 Mar 2007 17:47:01 -0400
Date: Thu, 29 Mar 2007 14:46:52 -0700 (PDT)
Message-Id: <20070329.144652.95503764.davem@davemloft.net>
To: jengelh@linux01.gwdg.de
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
From: David Miller <davem@davemloft.net>
In-Reply-To: <Pine.LNX.4.61.0703292341370.31834@yvahk01.tjqt.qr>
References: <e8f45b9e0703291439q505c6a06re003e91484a20354@mail.gmail.com>
	<Pine.LNX.4.61.0703292341370.31834@yvahk01.tjqt.qr>
X-Mailer: Mew version 5.1.52 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date: Thu, 29 Mar 2007 23:42:17 +0200 (MEST)

> > unsubscribe linux-kernel ..
> 
> I wonder why people can't send their unsubscribe message to the same 
> address they sent their subscribe message to.

People get frustrated that it doesn't work then start doing stupid
things like sending it to the actual list, like this person did.

Of course they always fail to consider doing the proper thing which is
to ask postmaster@vger.kernel.org or the list owner
(linux-kernel-owner@vger.kernel.org in this case) for help if it is
the case that their email has changed and they no longer have a way to
send from the subscribed address.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1422639AbXC2VsP@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1422639AbXC2VsP (ORCPT <rfc822;w@1wt.eu>);
	Thu, 29 Mar 2007 17:48:15 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422642AbXC2VsP
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 29 Mar 2007 17:48:15 -0400
Received: from ug-out-1314.google.com ([66.249.92.175]:41415 "EHLO
	ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1422639AbXC2VsO (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 29 Mar 2007 17:48:14 -0400
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=FocaS4H63KhYf8xxYV9zw5lrUvC/xxBmZ0VmXIgzFodUCPJVAJ7l8Ww+5uiqUNQTypoGhuTCtvjijvEFxjpRbV0wIrPV/vQsglEh/xtb+KIxFBp3tTcvVb1l/qpWlO5gwd9gdpA5lrxwwvQ5xSQ6T92Hj2f+COV953mLkLMKUIc=
Message-ID: <e8f45b9e0703291448v749efee2w8f1e415d003e1fb9@mail.gmail.com>
Date: Thu, 29 Mar 2007 23:48:11 +0200
From: "Gerard Braad" <gbraad@member.fsf.org>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <Pine.LNX.4.61.0703292341370.31834@yvahk01.tjqt.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e8f45b9e0703291439q505c6a06re003e91484a20354@mail.gmail.com>
	 <Pine.LNX.4.61.0703292341370.31834@yvahk01.tjqt.qr>
X-Google-Sender-Auth: 4f956532a96f4620
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Sorry, this wasn't supposed to happen. Already done...
Unsubscribed due to lack of a digest mail.

> I wonder why people can't send their unsubscribe message to the same
> address they sent their subscribe message to.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1762726AbXEPQoK@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1762726AbXEPQoK (ORCPT <rfc822;w@1wt.eu>);
	Wed, 16 May 2007 12:44:10 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760008AbXEPQny
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 16 May 2007 12:43:54 -0400
Received: from e33.co.us.ibm.com ([32.97.110.151]:48646 "EHLO
	e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1761473AbXEPQnx (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 16 May 2007 12:43:53 -0400
Date: Wed, 16 May 2007 11:43:41 -0500
To: Bob Picco <bob.picco@hp.com>, johnrose@us.ibm.com
Cc: Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@ozlabs.org,
       linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20070516164341.GA7008@austin.ibm.com>
References: <20070516133046.GB25792@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070516133046.GB25792@localhost>
User-Agent: Mutt/1.5.11
From: linas@austin.ibm.com (Linas Vepstas)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> 
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> make[3]: *** [drivers/pci/hotplug] Error 2
> make[2]: *** [drivers/pci] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2

John Rose is working to fix this "real soon now".

--linas

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1762593AbXEPRHu@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1762593AbXEPRHu (ORCPT <rfc822;w@1wt.eu>);
	Wed, 16 May 2007 13:07:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756943AbXEPRHn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 16 May 2007 13:07:43 -0400
Received: from lixom.net ([66.141.50.11]:39146 "EHLO mail.lixom.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755222AbXEPRHm (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 16 May 2007 13:07:42 -0400
Date: Wed, 16 May 2007 12:11:00 -0500
To: Linas Vepstas <linas@austin.ibm.com>
Cc: Bob Picco <bob.picco@hp.com>, johnrose@us.ibm.com, linuxppc-dev@ozlabs.org,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20070516171100.GA25056@lixom.net>
References: <20070516133046.GB25792@localhost> <20070516164341.GA7008@austin.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070516164341.GA7008@austin.ibm.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: olof@lixom.net (Olof Johansson)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > 
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
> 
> John Rose is working to fix this "real soon now".

Do you mean the fix Al Viro posted yesterday?

http://patchwork.ozlabs.org/linuxppc/patch?id=11177


-Olof

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S932097AbXEPRYc@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932097AbXEPRYc (ORCPT <rfc822;w@1wt.eu>);
	Wed, 16 May 2007 13:24:32 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757318AbXEPRYZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 16 May 2007 13:24:25 -0400
Received: from smtp.cce.hp.com ([161.114.21.22]:3522 "EHLO
	ccerelrim01.cce.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756283AbXEPRYZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 16 May 2007 13:24:25 -0400
From: "Bob Picco" <bob.picco@hp.com>
Date: Wed, 16 May 2007 13:24:21 -0400
To: Olof Johansson <olof@lixom.net>
Cc: Linas Vepstas <linas@austin.ibm.com>, Bob Picco <bob.picco@hp.com>,
       johnrose@us.ibm.com, linuxppc-dev@ozlabs.org,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20070516172421.GC25792@localhost>
References: <20070516133046.GB25792@localhost> <20070516164341.GA7008@austin.ibm.com> <20070516171100.GA25056@lixom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070516171100.GA25056@lixom.net>
User-Agent: Mutt/1.5.11
X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.16.101035
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Olof Johansson wrote:	[Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > > 
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> > 
> > John Rose is working to fix this "real soon now".
> 
> Do you mean the fix Al Viro posted yesterday?
> 
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
> 
> 
> -Olof
Missed that patch.

thanks,

bob

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S936416AbXJQQgf@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S936416AbXJQQgf (ORCPT <rfc822;w@1wt.eu>);
	Wed, 17 Oct 2007 12:36:35 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S936089AbXJQQgV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 17 Oct 2007 12:36:21 -0400
Received: from sovereign.computergmbh.de ([85.214.69.204]:49928 "EHLO
	sovereign.computergmbh.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S935991AbXJQQgU (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 17 Oct 2007 12:36:20 -0400
Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
From: Jan Engelhardt <jengelh@computergmbh.de>
To: nicholas.thompson1@mchsi.com
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <101720071630.22047.4716389F000E33190000561F219792474103010CD2079C080C03BFCE02019C9F0301089BD29C0E0401080C0702@mchsi.com>
Message-ID: <Pine.LNX.4.64.0710171836100.28622@fbirervta.pbzchgretzou.qr>
References: <101720071630.22047.4716389F000E33190000561F219792474103010CD2079C080C03BFCE02019C9F0301089BD29C0E0401080C0702@mchsi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>Date: Wed, 17 Oct 2007 16:30:24 +0000
>From:  <nicholas.thompson1@mchsi.com>
>To:  <linux-kernel@vger.kernel.org>
             ^^^^^^
>
>subscribe linux-alpha
                 ^^^^^


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S935741AbXJQRvN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S935741AbXJQRvN (ORCPT <rfc822;w@1wt.eu>);
	Wed, 17 Oct 2007 13:51:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751338AbXJQRu7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 17 Oct 2007 13:50:59 -0400
Received: from z2.cat.iki.fi ([212.16.98.133]:43800 "EHLO z2.cat.iki.fi"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1759330AbXJQRu6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 17 Oct 2007 13:50:58 -0400
Date: Wed, 17 Oct 2007 20:50:54 +0300
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20071017175054.GE6372@mea-ext.zmailer.org>
References: <101720071630.22047.4716389F000E33190000561F219792474103010CD2079C080C03BFCE02019C9F0301089BD29C0E0401080C0702@mchsi.com> <Pine.LNX.4.64.0710171836100.28622@fbirervta.pbzchgretzou.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0710171836100.28622@fbirervta.pbzchgretzou.qr>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Nope, wrong clues.
The right clues are in the footer of this message after it travels thru the list.

I supplied them to Nicholas already, but apparently others need to be reminded of
them every now and then  :-]   That footer is in these list messages for a reason!

    /Matti Aarnio -- one of  <postmaster@vger.kernel.org>

PS: You want to contact VGER's email and list managers ?
    We use the internet email standard address "postmaster"


On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
> From: Jan Engelhardt <jengelh@computergmbh.de>
> To: nicholas.thompson1@mchsi.com
> cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
> 
> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
> >Date: Wed, 17 Oct 2007 16:30:24 +0000
> >From:  <nicholas.thompson1@mchsi.com>
> >To:  <linux-kernel@vger.kernel.org>
>              ^^^^^^
> >
> >subscribe linux-alpha
>                  ^^^^^

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S932139AbXJQS2p@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932139AbXJQS2p (ORCPT <rfc822;w@1wt.eu>);
	Wed, 17 Oct 2007 14:28:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759404AbXJQS2Y
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 17 Oct 2007 14:28:24 -0400
Received: from sccmmhc92.asp.att.net ([204.127.203.212]:35138 "EHLO
	sccmmhc92.asp.att.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1759082AbXJQS2X (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 17 Oct 2007 14:28:23 -0400
From: nicholas.thompson1@mchsi.com
To: linux-kernel@vger.kernel.org
Subject: Re: your mail
Date: Wed, 17 Oct 2007 18:28:21 +0000
Message-Id: <101720071828.14460.471654440008AFC00000387C219792474103010CD2079C080C03BFCE02019C9F0301089BD29C0E0401080C0702@mchsi.com>
X-Mailer: AT&T Message Center Version 1 (May  3 2007)
X-Authenticated-Sender: bmljaG9sYXMudGhvbXBzb24xQG1jaHNpLmNvbQ==
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>Nope, wrong clues.
>The right clues are in the footer of this message after it travels thru the list.
>
>I supplied them to Nicholas already, but apparently others need to be reminded of
>them every now and then  :-]   That footer is in these list messages for a reason!
>
>    /Matti Aarnio -- one of  <postmaster@vger.kernel.org>
>
>PS: You want to contact VGER's email and list managers ?
>    We use the internet email standard address "postmaster"
>

Jan, Matti, + List,
 I am very sorry about the noise, that's what I get for using cut and paste while tired and before my third cup of coffee. ;p Apologies.

Nick 

>>On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
>> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
>> From: Jan Engelhardt <jengelh@computergmbh.de>
>> To: nicholas.thompson1@mchsi.com
>> cc: linux-kernel@vger.kernel.org
>> Subject: Re: your mail
>> 
>> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>> >Date: Wed, 17 Oct 2007 16:30:24 +0000
>> >From:  <nicholas.thompson1@mchsi.com>
>> >To:  <linux-kernel@vger.kernel.org>
>>              ^^^^^^
> >>
> >>subscribe linux-alpha
>>                  ^^^^^

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S933634AbYETPU3@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933634AbYETPU3 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 20 May 2008 11:20:29 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759263AbYETPUO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 20 May 2008 11:20:14 -0400
Received: from iolanthe.rowland.org ([192.131.102.54]:47111 "HELO
	iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with SMTP id S932524AbYETPUM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 20 May 2008 11:20:12 -0400
Date: Tue, 20 May 2008 11:20:10 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Lukas Hejtmanek <xhejtman@ics.muni.cz>
cc: Oliver Neukum <oliver@neukum.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       <greg@kroah.com>, <linux-usb@vger.kernel.org>
Subject: Re: your mail
In-Reply-To: <20080520123423.GA4764@ics.muni.cz>
Message-ID: <Pine.LNX.4.44L0.0805201117430.2114-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 20 May 2008, Lukas Hejtmanek wrote:

> <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
> Bcc: 
> Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
> 	until reload of ehci-hcd
> Reply-To: 
> In-Reply-To: <200805201327.34678.oliver@neukum.org>
> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
> 
> On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > > done.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=10630
> > 
> > Aha. Thanks.
> > Please recompile without CONFIG_USB_SUSPEND
> 
> Hm, without USB_SUSPEND it works. So what next, considered fixed or any
> further investigation is needed?

No further investigation is needed.  I tried doing essentially the same 
thing on my system and the same problem occurred.

It is caused by the way ehci-hcd "auto-clears" the port
change-suspend feature.  This patch should fix the problem.  Please 
try it out and let us know if it works.

Alan Stern



Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ -97,6 +97,8 @@ struct ehci_hcd {			/* one per controlle
 			dedicated to the companion controller */
 	unsigned long		owned_ports;		/* which ports are
 			owned by the companion during a bus suspend */
+	unsigned long		port_c_suspend;		/* which ports have
+			the change-suspend feature turned on */
 
 	/* per-HC memory pools (could be per-bus, but ...) */
 	struct dma_pool		*qh_pool;	/* qh per active urb */
Index: usb-2.6/drivers/usb/host/ehci-hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-hub.c
+++ usb-2.6/drivers/usb/host/ehci-hub.c
@@ -609,7 +609,7 @@ static int ehci_hub_control (
 			}
 			break;
 		case USB_PORT_FEAT_C_SUSPEND:
-			/* we auto-clear this feature */
+			clear_bit(wIndex, &ehci->port_c_suspend);
 			break;
 		case USB_PORT_FEAT_POWER:
 			if (HCS_PPC (ehci->hcs_params))
@@ -688,7 +688,7 @@ static int ehci_hub_control (
 			/* resume completed? */
 			else if (time_after_eq(jiffies,
 					ehci->reset_done[wIndex])) {
-				status |= 1 << USB_PORT_FEAT_C_SUSPEND;
+				set_bit(wIndex, &ehci->port_c_suspend);
 				ehci->reset_done[wIndex] = 0;
 
 				/* stop resume signaling */
@@ -765,6 +765,8 @@ static int ehci_hub_control (
 			status |= 1 << USB_PORT_FEAT_RESET;
 		if (temp & PORT_POWER)
 			status |= 1 << USB_PORT_FEAT_POWER;
+		if (test_bit(wIndex, &ehci->port_c_suspend))
+			status |= 1 << USB_PORT_FEAT_C_SUSPEND;
 
 #ifndef	VERBOSE_DEBUG
 	if (status & ~0xffff)	/* only if wPortChange is interesting */


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1761457AbYEXUGr@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1761457AbYEXUGr (ORCPT <rfc822;w@1wt.eu>);
	Sat, 24 May 2008 16:06:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754146AbYEXUGi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 24 May 2008 16:06:38 -0400
Received: from www.tglx.de ([62.245.132.106]:58698 "EHLO www.tglx.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753751AbYEXUGh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 24 May 2008 16:06:37 -0400
Date: Sat, 24 May 2008 22:05:53 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Walker <dwalker@mvista.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <alpine.LFD.1.10.0805242149170.3295@apollo.tec.linutronix.de>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 24 May 2008, Daniel Walker wrote:
> > There is no kernel side controlled handover of a normal futex. The
> > woken up waiters race for it and a low prio thread on another CPU can
> > steal it even if there is a high prio waiter woken up.
> 
> After reading futex_wake, Doesn't it depend how many waiters are woken?
> Given that comes from userspace, glibc could wake a single waiter and
> obtain a priority ordering, couldn't it?

It could and it does. Still this does not protect against another
lower prio task taking the futex before the woken waiter can do it,
which is happening way more often than your theoretical setscheduler
case. Again, setscheduler is called in startup code of a program not
at arbitrary points during runtime, which rely on lock ordering.

> > The plist add on works correct in most of the cases, nothing else. To
> > achieve full correctness there is much more necessary than this
> > setscheduler issue. The plist changes were accepted because the
> > overhead is really minimal, but achieving full correctness would hurt
> > performance badly.
> 
> If that's the requirement then code that cleans up the corner case that
> I've identified, which is also minimal should be acceptable .. Since
> it's meeting the same requirement you layed out above for the original
> plist changes.

Your code solves the least to worry about corner case and hurts
performance for nothing. You take extra locks in the hot path for no
benefit.

Aside of that it introduces lock order problems and we can really do
without extra useless complexity in the futex code.

You can argue in circles. This is not going anywhere near mainline.

Thanks,
	tglx

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1762414AbYEXVGb@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1762414AbYEXVGb (ORCPT <rfc822;w@1wt.eu>);
	Sat, 24 May 2008 17:06:31 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758220AbYEXVGY
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 24 May 2008 17:06:24 -0400
Received: from gateway-1237.mvista.com ([63.81.120.158]:24424 "EHLO
	gateway-1237.mvista.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758060AbYEXVGY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 24 May 2008 17:06:24 -0400
Subject: Re: your mail
From: Daniel Walker <dwalker@mvista.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <alpine.LFD.1.10.0805242149170.3295@apollo.tec.linutronix.de>
References: <alpine.LFD.1.10.0805242149170.3295@apollo.tec.linutronix.de>
Content-Type: text/plain
Date: Sat, 24 May 2008 14:06:21 -0700
Message-Id: <1211663181.18130.203.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) 
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On Sat, 2008-05-24 at 22:05 +0200, Thomas Gleixner wrote:

> > If that's the requirement then code that cleans up the corner case that
> > I've identified, which is also minimal should be acceptable .. Since
> > it's meeting the same requirement you layed out above for the original
> > plist changes.
> 
> Your code solves the least to worry about corner case and hurts
> performance for nothing. You take extra locks in the hot path for no
> benefit.
> 
> Aside of that it introduces lock order problems and we can really do
> without extra useless complexity in the futex code.
> 
> You can argue in circles. This is not going anywhere near mainline.

Above I'm not speaking about my code, I'm only speaking in terms of a
solution to this case, even if it isn't mine..

Daniel




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752332AbZAKGrW@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752332AbZAKGrW (ORCPT <rfc822;w@1wt.eu>);
	Sun, 11 Jan 2009 01:47:22 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751068AbZAKGrN
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 11 Jan 2009 01:47:13 -0500
Received: from swampdragon.chaosbits.net ([90.184.90.115]:18515 "EHLO
	swampdragon.chaosbits.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751046AbZAKGrN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 11 Jan 2009 01:47:13 -0500
Date: Sun, 11 Jan 2009 07:47:11 +0100 (CET)
From: Jesper Juhl <jj@chaosbits.net>
To: Jose Luis Marchetti <joseluismarchetti@yahoo.com.br>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <204164.94418.qm@web34403.mail.mud.yahoo.com>
Message-ID: <alpine.LNX.2.00.0901110738550.21183@swampdragon.chaosbits.net>
References: <204164.94418.qm@web34403.mail.mud.yahoo.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 10 Jan 2009, Jose Luis Marchetti wrote:

> Hi,
> 
> I would like to open/read/write/close a regular file from my device
> driver.

That's probably a bad idea and what you really want to do is use procfs, 
sysfs, debugfs, relayfs, module parameters or similar.

Take a look here: 
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad 


-- 
Jesper Juhl <jj@chaosbits.net>        http://personal.chaosbits.net/
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1759940AbZAMNVz@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1759940AbZAMNVz (ORCPT <rfc822;w@1wt.eu>);
	Tue, 13 Jan 2009 08:21:55 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756833AbZAMNVp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 13 Jan 2009 08:21:45 -0500
Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:53364 "EHLO
	hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756534AbZAMNVo (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 13 Jan 2009 08:21:44 -0500
Date: Tue, 13 Jan 2009 08:21:41 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20090113132141.GB21687@goodmis.org>
References: <20090113061004.156004985@goodmis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090113061004.156004985@goodmis.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jan 13, 2009 at 01:10:04AM -0500, Steven Rostedt wrote:

Bah! sorry for the noise here. My scripts to send out the patch
queue failed to handle the comma in "Luck, Tony" email address.
But it unfortunately did a partial send :-(

I had to modify Tony's email for the final send.

-- Steve


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758603AbZASDIB@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758603AbZASDIB (ORCPT <rfc822;w@1wt.eu>);
	Sun, 18 Jan 2009 22:08:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757682AbZASDHt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 18 Jan 2009 22:07:49 -0500
Received: from palinux.external.hp.com ([192.25.206.14]:52485 "EHLO
	mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757667AbZASDHs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 18 Jan 2009 22:07:48 -0500
Date: Sun, 18 Jan 2009 20:07:32 -0700
From: Matthew Wilcox <matthew@wil.cx>
To: "Gao, Yunpeng" <yunpeng.gao@intel.com>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
       "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20090119030731.GA28670@parisc-linux.org>
References: <38D9F46DFF92C54980D2F2C1E8EE31301FC5E7FB@pdsmsx503.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <38D9F46DFF92C54980D2F2C1E8EE31301FC5E7FB@pdsmsx503.ccr.corp.intel.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 19, 2009 at 10:54:02AM +0800, Gao, Yunpeng wrote:
> I have to use 64bit variable in my 2.6.27 kernel NAND driver as below:
> ---------------------------------------------------------------------------
> u64 NAND_capacity;
> unsigned int block_num, block_size;
> ...
> block_num = NAND_capacity / block_size;
> ---------------------------------------------------------------------------
> but it failed when compiling and reports 'undefined reference to `__udivdi3'.

Presumably block_size is a power of two, so you can do:

	block_num = NAND_capacity >> block_shift;

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1761157AbZBMDlR@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1761157AbZBMDlR (ORCPT <rfc822;w@1wt.eu>);
	Thu, 12 Feb 2009 22:41:17 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756545AbZBMDlB
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 12 Feb 2009 22:41:01 -0500
Received: from cmpxchg.org ([85.214.51.133]:45148 "EHLO cmpxchg.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755961AbZBMDlB (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 12 Feb 2009 22:41:01 -0500
Date: Fri, 13 Feb 2009 04:40:32 +0100
From: Johannes Weiner <hannes@cmpxchg.org>
To: Youngwhan Kim <cs010101@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20090213034032.GB13631@cmpxchg.org>
References: <9C93882871B24A1FB0068781AB79D12A@jamesnotebook>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C93882871B24A1FB0068781AB79D12A@jamesnotebook>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Feb 13, 2009 at 09:45:13AM +0900, Youngwhan Kim wrote:
> unsubscribe

There is just no way out!

> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org        ^^^^^^^^^^^^

                           ^^^^^^^^^^^^^^^^^^^^^^^^^

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1755742AbZCKPEi@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755742AbZCKPEi (ORCPT <rfc822;w@1wt.eu>);
	Wed, 11 Mar 2009 11:04:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752638AbZCKPEa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 11 Mar 2009 11:04:30 -0400
Received: from smtp1.linux-foundation.org ([140.211.169.13]:40825 "EHLO
	smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752714AbZCKPE3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 Mar 2009 11:04:29 -0400
Date: Wed, 11 Mar 2009 07:59:07 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
X-X-Sender: torvalds@localhost.localdomain
To: Vitaly Mayatskikh <v.mayatskih@gmail.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <87ljrccp57.wl%vmayatsk@redhat.com>
Message-ID: <alpine.LFD.2.00.0903110756180.32478@localhost.localdomain>
References: <87ljrccp57.wl%vmayatsk@redhat.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
> 
> (v)scnprintf says it should return 0 when size is 0, but doesn't do
> so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> comments.

That is bogus.

The code really does (od "did"? Maybe you removed it) check for _smaller_ 
than 0:

	int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
	{
		...
		/* Reject out-of-range values early.  Large positive sizes are
		   used for unknown buffer sizes. */
		if (unlikely((int) size < 0)) {
			/* There can be only one.. */
			static char warn = 1;
			WARN_ON(warn);
			warn = 0;
			return 0;
		}
		...

because under/overflows have happened.

The kernel is _not_ a regular libc. We have different rules.

		Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754195AbZCKRXN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754195AbZCKRXN (ORCPT <rfc822;w@1wt.eu>);
	Wed, 11 Mar 2009 13:23:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752191AbZCKRW5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 11 Mar 2009 13:22:57 -0400
Received: from mail-ew0-f177.google.com ([209.85.219.177]:38470 "EHLO
	mail-ew0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751670AbZCKRW4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 Mar 2009 13:22:56 -0400
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:message-id:from:to:cc:subject:in-reply-to:references
         :user-agent:mime-version:content-type;
        b=YRA9FMvknyPG3E46JUr4P3GY4odNN5ruLtodJJxmmNfajmo9d6lARuElZlF5HeRgi9
         vCBeJUcNPqa8HQ2ntfb155QqocCIU8xg5BjtknZoeB4KT3DTpN8s62nEHsRx19NbB8gi
         wTcD1yoKzWaYQt94EEEoCyOwrHEPxHbst0Yz0=
Date: Wed, 11 Mar 2009 18:23:08 +0100
Message-ID: <8763ig7z43.wl%vmayatsk@redhat.com>
From: Vitaly Mayatskikh <v.mayatskih@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vitaly Mayatskikh <v.mayatskih@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: your mail
In-Reply-To: <alpine.LFD.2.00.0903110756180.32478@localhost.localdomain>
References: <87ljrccp57.wl%vmayatsk@redhat.com>
	<alpine.LFD.2.00.0903110756180.32478@localhost.localdomain>
User-Agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
> > 
> > (v)scnprintf says it should return 0 when size is 0, but doesn't do
> > so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> > comments.
> 
> That is bogus.
> 
> The code really does (od "did"? Maybe you removed it) check for _smaller_ 
> than 0:

Well, (v)scnprintf says it returns 0 for size <= 0, but really returns
-1 for size == 0. I think, this code can't return 0 for size == 0:

	i=vsnprintf(buf,size,fmt,args);
	return (i >= size) ? (size - 1) : i;

Systemtap's script:

function test:long()
%{
        char tmp[256];
        long err;
        err = scnprintf(tmp, 0, "%lu", (long)128);
        THIS->__retvalue = err;
%}

probe begin
{
        printf("scnprintf returns %d\n", test());
}

stap -g scnprintf.stp
scnprintf returns -1

-- 
wbr, Vitaly

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1760588AbZCMRCx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760588AbZCMRCx (ORCPT <rfc822;w@1wt.eu>);
	Fri, 13 Mar 2009 13:02:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759674AbZCMRBB
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 13 Mar 2009 13:01:01 -0400
Received: from kotten8a.marieberg.ac ([213.238.238.22]:40058 "HELO
	iluvatar.nyren.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with SMTP id S1759610AbZCMRBA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 13 Mar 2009 13:01:00 -0400
X-Greylist: delayed 399 seconds by postgrey-1.27 at vger.kernel.org; Fri, 13 Mar 2009 13:00:59 EDT
Date: Fri, 13 Mar 2009 17:54:09 +0100 (CET)
From: Ralf Nyren <ralf@nyren.net>
X-X-Sender: plumbum@fujje.iml.umu.se
To: Rory Filer <rfiler@SierraWireless.com>
cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
       Kevin Lloyd <klloyd@SierraWireless.com>
Subject: Re: your mail
In-Reply-To: <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>
Message-ID: <alpine.DEB.1.10.0903131751120.8432@fujje.iml.umu.se>
References: <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Rory,

Sounds great, send the driver and I'll give it a try at once. I'll report back
to you with the results.

Many thanks, Ralf

On Fri, 13 Mar 2009, Rory Filer wrote:

> Hi Ralf
>
>
>
> Kevin passed your email on to my attention and I think we can help you with this problem. We've been doing a lot of work on our drivers lately and I've got a freshly-ready version of sierra.c just for 2.6.28. We've done a lot of testing here and it seems pretty robust; perhaps you'd be willing to give it a try?
>
>
>
> Since I'm not sure about the etiquette for posting to this list, so I will attach the driver in a separate email to you.
>
>
>
> Regards
>
>
>
> Rory Filer
>
>
>
>
>
> -----Original Message-----
>
> From: Ralf Nyren [mailto:ralf@nyren.net]
>
> Sent: Friday, March 13, 2009 8:01 AM
>
> To: linux-kernel@vger.kernel.org
>
> Cc: Kevin Lloyd
>
> Subject: Sierra Wireless (MC8780) HSDPA speed issue
>
>
>
> Hi,
>
>
>
> I have a Sierra Wireless MC8780 UMTS card in a Fujitsu S6410 laptop running kernel 2.6.28.7. In kernel sierra driver v1.3.2.
>
>
>
> The card works but speed seems limited to approx 1.0 Mbit/s download using the linux driver.  Testing the card in Windows XP yields download speeds close to 5.0 Mbit/s.
>
>
>
> I recently updated the firmware of the card to support HSDPA/HSUPA. The update gave the desired result in Windows but not in Linux. The speed improved in Linux but didn't increase above 1 Mbit/s.
>
>
>
> Is there any known driver limitations or is this a configuration issue?
>
>
>
> Please let me know if you need any additional information.
>
>
>
> Best regards, Ralf
>
>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1756740AbZC1AEm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756740AbZC1AEm (ORCPT <rfc822;w@1wt.eu>);
	Fri, 27 Mar 2009 20:04:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751034AbZC1AEc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 27 Mar 2009 20:04:32 -0400
Received: from smtp1.linux-foundation.org ([140.211.169.13]:51736 "EHLO
	smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1750830AbZC1AEc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 27 Mar 2009 20:04:32 -0400
Date: Fri, 27 Mar 2009 17:02:04 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
X-X-Sender: torvalds@localhost.localdomain
To: Eric Anholt <eric@anholt.net>
cc: lkml <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.sf.net>
Subject: Re: your mail
In-Reply-To: <1238196389.625.430.camel@gaiman.anholt.net>
Message-ID: <alpine.LFD.2.00.0903271657360.3994@localhost.localdomain>
References: <1238196389.625.430.camel@gaiman.anholt.net>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On Fri, 27 Mar 2009, Eric Anholt wrote:
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next

Grr.

Guys, what the *hell* is wrong with you, when you can't even react to 
trivial warnings and fix buggy code pointed out by the compiler?

If you had _ever_ compiled this on x86-64, you would have seen:

  drivers/gpu/drm/i915/i915_gem_debugfs.c: In function âi915_gem_fence_regs_infoâ:
  drivers/gpu/drm/i915/i915_gem_debugfs.c:201: warning: format â%08xâ expects type âunsigned intâ, but argument 7 has type âsize_tâ

and this is not the first time this has happened.

See commits f06da264cfb0f9444d41ca247213e419f90aa72a and 
aeb565dfc3ac4c8b47c5049085b4c7bfb2c7d5d7.

What's so hard with keeping the build warning-clean, and fixing these 
things _long_ before they hit my tree?

Some basic quality control. PLEASE.

		Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1760889AbZEGKVY@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760889AbZEGKVY (ORCPT <rfc822;w@1wt.eu>);
	Thu, 7 May 2009 06:21:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756060AbZEGKVL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 7 May 2009 06:21:11 -0400
Received: from mx3.mail.elte.hu ([157.181.1.138]:49218 "EHLO mx3.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756035AbZEGKVJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 7 May 2009 06:21:09 -0400
Date: Thu, 7 May 2009 12:20:15 +0200
From: Ingo Molnar <mingo@elte.hu>
To: James Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@sous-sol.org>, Oleg Nesterov <oleg@redhat.com>,
       Roland McGrath <roland@redhat.com>,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       Al Viro <viro@ZenIV.linux.org.uk>,
       linux-security-module@vger.kernel.org
Subject: Re: your mail
Message-ID: <20090507102015.GB8901@elte.hu>
References: <20090506235349.GC3756@redhat.com> <20090507002133.02D05FC39E@magilla.sf.frob.com> <20090507063606.GA15220@redhat.com> <20090507082027.GD12285@elte.hu> <20090507083102.GA20125@redhat.com> <20090507083851.GA19133@elte.hu> <20090507085742.GB3036@sequoia.sous-sol.org> <20090507090459.GE19133@elte.hu> <20090507092009.GC3036@sequoia.sous-sol.org> <alpine.LRH.2.00.0905071951530.29219@tundra.namei.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.00.0905071951530.29219@tundra.namei.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: -1.5
X-ELTE-SpamLevel: 
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0 
X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3
	-1.5 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* James Morris <jmorris@namei.org> wrote:

> On Thu, 7 May 2009, Chris Wright wrote:
> 
> > * Ingo Molnar (mingo@elte.hu) wrote:
> 
> [Added LSM list to the CC; please do so whenever making changes in this 
> area...]
> 
> > > They have no active connection to the core kernel 
> > > ptrace_may_access() check in any case:
> > 
> > Not sure what you mean:
> > 
> > ptrace_may_access
> >  __ptrace_may_access
> >   security_ptrace_may_access
> > 
> > Looks like your patch won't compile.
> > 
> 
> Below is an updated version which fixes the bug, against 
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
> 
> Boot tested with SELinux.

thanks! Below are the two patches i wrote and tested.

	Ingo

----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----

Date: Thu, 7 May 2009 11:49:47 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
	ptrace_access_check
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>

The ptrace_may_access() methods are named confusingly - some 
variants return a bool, while the security subsystem methods have a 
retval convention.

Rename it to ptrace_access_check, to reduce the confusion factor. A 
followup patch eliminates the bool usage.

[ Impact: cleanup, no code changed ]

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
LKML-Reference: <20090507084943.GB19133@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 fs/proc/array.c            |    2 +-
 fs/proc/base.c             |   10 +++++-----
 fs/proc/task_mmu.c         |    2 +-
 include/linux/ptrace.h     |    4 ++--
 include/linux/security.h   |   14 +++++++-------
 kernel/ptrace.c            |   10 +++++-----
 security/capability.c      |    2 +-
 security/commoncap.c       |    4 ++--
 security/root_plug.c       |    2 +-
 security/security.c        |    4 ++--
 security/selinux/hooks.c   |    6 +++---
 security/smack/smack_lsm.c |    8 ++++----
 12 files changed, 34 insertions(+), 34 deletions(-)

Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file 
 
 	state = *get_task_state(task);
 	vsize = eip = esp = 0;
-	permitted = ptrace_may_access(task, PTRACE_MODE_READ);
+	permitted = ptrace_access_check(task, PTRACE_MODE_READ);
 	mm = get_task_mm(task);
 	if (mm) {
 		vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
 		rcu_read_lock();
 		match = (tracehook_tracer_task(task) == current);
 		rcu_read_unlock();
-		if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
+		if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
 			return 0;
 	}
 
@@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
 	if (task->mm != mm)
 		goto out;
 	if (task->mm != current->mm &&
-	    __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
+	    __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
 		goto out;
 	task_unlock(task);
 	return mm;
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
 	wchan = get_wchan(task);
 
 	if (lookup_symbol_name(wchan, symname) < 0)
-		if (!ptrace_may_access(task, PTRACE_MODE_READ))
+		if (!ptrace_access_check(task, PTRACE_MODE_READ))
 			return 0;
 		else
 			return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
 	 */
 	task = get_proc_task(inode);
 	if (task) {
-		allowed = ptrace_may_access(task, PTRACE_MODE_READ);
+		allowed = ptrace_access_check(task, PTRACE_MODE_READ);
 		put_task_struct(task);
 	}
 	return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file 
 	if (!task)
 		goto out_no_task;
 
-	if (!ptrace_may_access(task, PTRACE_MODE_READ))
+	if (!ptrace_access_check(task, PTRACE_MODE_READ))
 		goto out;
 
 	ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file 
 		goto out;
 
 	ret = -EACCES;
-	if (!ptrace_may_access(task, PTRACE_MODE_READ))
+	if (!ptrace_access_check(task, PTRACE_MODE_READ))
 		goto out_task;
 
 	ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
 #define PTRACE_MODE_READ   1
 #define PTRACE_MODE_ATTACH 2
 /* Returns 0 on success, -errno on denial. */
-extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
 /* Returns true on success, false on denial. */
-extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
 
 static inline int ptrace_reparented(struct task_struct *child)
 {
Index: linux/include/linux/security.h
===================================================================
--- linux.orig/include/linux/security.h
+++ linux/include/linux/security.h
@@ -52,7 +52,7 @@ struct audit_krule;
 extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
 		       int cap, int audit);
 extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
 extern int cap_ptrace_traceme(struct task_struct *parent);
 extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
 extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
  *	@alter contains the flag indicating whether changes are to be made.
  *	Return 0 if permission is granted.
  *
- * @ptrace_may_access:
+ * @ptrace_access_check:
  *	Check permission before allowing the current process to trace the
  *	@child process.
  *	Security modules may also want to perform a process tracing check
@@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
  *	Check that the @parent process has sufficient permission to trace the
  *	current process before allowing the current process to present itself
  *	to the @parent process for tracing.
- *	The parent process will still have to undergo the ptrace_may_access
+ *	The parent process will still have to undergo the ptrace_access_check
  *	checks before it is allowed to trace this one.
  *	@parent contains the task_struct structure for debugger process.
  *	Return 0 if permission is granted.
@@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
 struct security_operations {
 	char name[SECURITY_NAME_MAX + 1];
 
-	int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+	int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
 	int (*ptrace_traceme) (struct task_struct *parent);
 	int (*capget) (struct task_struct *target,
 		       kernel_cap_t *effective,
@@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
 extern int register_security(struct security_operations *ops);
 
 /* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
 int security_ptrace_traceme(struct task_struct *parent);
 int security_capget(struct task_struct *target,
 		    kernel_cap_t *effective,
@@ -1798,10 +1798,10 @@ static inline int security_init(void)
 	return 0;
 }
 
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
 					     unsigned int mode)
 {
-	return cap_ptrace_may_access(child, mode);
+	return cap_ptrace_access_check(child, mode);
 }
 
 static inline int security_ptrace_traceme(struct task_struct *parent)
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
 	return ret;
 }
 
-int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int __ptrace_access_check(struct task_struct *task, unsigned int mode)
 {
 	const struct cred *cred = current_cred(), *tcred;
 
@@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
 	if (!dumpable && !capable(CAP_SYS_PTRACE))
 		return -EPERM;
 
-	return security_ptrace_may_access(task, mode);
+	return security_ptrace_access_check(task, mode);
 }
 
-bool ptrace_may_access(struct task_struct *task, unsigned int mode)
+bool ptrace_access_check(struct task_struct *task, unsigned int mode)
 {
 	int err;
 	task_lock(task);
-	err = __ptrace_may_access(task, mode);
+	err = __ptrace_access_check(task, mode);
 	task_unlock(task);
 	return !err;
 }
@@ -217,7 +217,7 @@ repeat:
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)
 		goto bad;
-	retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
+	retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
 	if (retval)
 		goto bad;
 
Index: linux/security/capability.c
===================================================================
--- linux.orig/security/capability.c
+++ linux/security/capability.c
@@ -863,7 +863,7 @@ struct security_operations default_secur
 
 void security_fixup_ops(struct security_operations *ops)
 {
-	set_to_cap_if_null(ops, ptrace_may_access);
+	set_to_cap_if_null(ops, ptrace_access_check);
 	set_to_cap_if_null(ops, ptrace_traceme);
 	set_to_cap_if_null(ops, capget);
 	set_to_cap_if_null(ops, capset);
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c
+++ linux/security/commoncap.c
@@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
 }
 
 /**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
  *			   another
  * @child: The process to be accessed
  * @mode: The mode of attachment.
@@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
  * Determine whether a process may access another, returning 0 if permission
  * granted, -ve if denied.
  */
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
 {
 	int ret = 0;
 
Index: linux/security/root_plug.c
===================================================================
--- linux.orig/security/root_plug.c
+++ linux/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security 
 
 static struct security_operations rootplug_security_ops = {
 	/* Use the capability functions for some of the hooks */
-	.ptrace_may_access =		cap_ptrace_may_access,
+	.ptrace_access_check =		cap_ptrace_access_check,
 	.ptrace_traceme =		cap_ptrace_traceme,
 	.capget =			cap_capget,
 	.capset =			cap_capset,
Index: linux/security/security.c
===================================================================
--- linux.orig/security/security.c
+++ linux/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_op
 
 /* Security operations */
 
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
 {
-	return security_ops->ptrace_may_access(child, mode);
+	return security_ops->ptrace_access_check(child, mode);
 }
 
 int security_ptrace_traceme(struct task_struct *parent)
Index: linux/security/selinux/hooks.c
===================================================================
--- linux.orig/security/selinux/hooks.c
+++ linux/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
 
 /* Hook functions begin here. */
 
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
 				     unsigned int mode)
 {
 	int rc;
 
-	rc = cap_ptrace_may_access(child, mode);
+	rc = cap_ptrace_access_check(child, mode);
 	if (rc)
 		return rc;
 
@@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
 static struct security_operations selinux_ops = {
 	.name =				"selinux",
 
-	.ptrace_may_access =		selinux_ptrace_may_access,
+	.ptrace_access_check =		selinux_ptrace_access_check,
 	.ptrace_traceme =		selinux_ptrace_traceme,
 	.capget =			selinux_capget,
 	.capset =			selinux_capset,
Index: linux/security/smack/smack_lsm.c
===================================================================
--- linux.orig/security/smack/smack_lsm.c
+++ linux/security/smack/smack_lsm.c
@@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
  */
 
 /**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
  * @ctp: child task pointer
  * @mode: ptrace attachment mode
  *
@@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
  *
  * Do the capability checks, and require read and write.
  */
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
 {
 	int rc;
 
-	rc = cap_ptrace_may_access(ctp, mode);
+	rc = cap_ptrace_access_check(ctp, mode);
 	if (rc != 0)
 		return rc;
 
@@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
 struct security_operations smack_ops = {
 	.name =				"smack",
 
-	.ptrace_may_access =		smack_ptrace_may_access,
+	.ptrace_access_check =		smack_ptrace_access_check,
 	.ptrace_traceme =		smack_ptrace_traceme,
 	.capget = 			cap_capget,
 	.capset = 			cap_capset,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----
----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----

Date: Thu, 7 May 2009 11:50:54 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
	function
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>

ptrace_access_check() returns a bool, while most of the ptrace 
access check machinery works with Linux retvals (where 0 indicates 
success, negative indicates an error).

So eliminate the bool and invert the usage at the call sites.

( Note: "< 0" checks are used instead of !0 checks, because that's
  the convention for retval checks and it results in similarly fast
  assembly code. )

[ Impact: cleanup ]

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 fs/proc/array.c        |    2 +-
 fs/proc/base.c         |    8 ++++----
 fs/proc/task_mmu.c     |    2 +-
 include/linux/ptrace.h |    2 +-
 kernel/ptrace.c        |    6 ++++--
 5 files changed, 11 insertions(+), 9 deletions(-)

Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file 
 
 	state = *get_task_state(task);
 	vsize = eip = esp = 0;
-	permitted = ptrace_access_check(task, PTRACE_MODE_READ);
+	permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
 	mm = get_task_mm(task);
 	if (mm) {
 		vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
 		rcu_read_lock();
 		match = (tracehook_tracer_task(task) == current);
 		rcu_read_unlock();
-		if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
+		if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
 			return 0;
 	}
 
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
 	wchan = get_wchan(task);
 
 	if (lookup_symbol_name(wchan, symname) < 0)
-		if (!ptrace_access_check(task, PTRACE_MODE_READ))
+		if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
 			return 0;
 		else
 			return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
 	 */
 	task = get_proc_task(inode);
 	if (task) {
-		allowed = ptrace_access_check(task, PTRACE_MODE_READ);
+		allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
 		put_task_struct(task);
 	}
 	return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file 
 	if (!task)
 		goto out_no_task;
 
-	if (!ptrace_access_check(task, PTRACE_MODE_READ))
+	if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
 		goto out;
 
 	ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file 
 		goto out;
 
 	ret = -EACCES;
-	if (!ptrace_access_check(task, PTRACE_MODE_READ))
+	if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
 		goto out_task;
 
 	ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
 /* Returns 0 on success, -errno on denial. */
 extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
 /* Returns true on success, false on denial. */
-extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
+extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
 
 static inline int ptrace_reparented(struct task_struct *child)
 {
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
 	return security_ptrace_access_check(task, mode);
 }
 
-bool ptrace_access_check(struct task_struct *task, unsigned int mode)
+int ptrace_access_check(struct task_struct *task, unsigned int mode)
 {
 	int err;
+
 	task_lock(task);
 	err = __ptrace_access_check(task, mode);
 	task_unlock(task);
-	return !err;
+
+	return err;
 }
 
 int ptrace_attach(struct task_struct *task)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1762252AbZEHD1t@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1762252AbZEHD1t (ORCPT <rfc822;w@1wt.eu>);
	Thu, 7 May 2009 23:27:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755617AbZEHD1h
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 7 May 2009 23:27:37 -0400
Received: from smtp107.prem.mail.sp1.yahoo.com ([98.136.44.62]:25903 "HELO
	smtp107.prem.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with SMTP id S1754968AbZEHD1f (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 7 May 2009 23:27:35 -0400
X-YMail-OSG: A0OqbZ4VM1l.haRAe6wcElT9m3VX5lET424AeZhUI3OayZ1eyheCUuAZKwtUcbvdhqWBWkOryWkhxtVpN8nBkd6COwQHsISIAnvyxmiCGDP1lzhShIITs0OflPzvbLEDoRIoV5IuyaWY1eJPXr.xnHRWlat3GE9Nz4S9DSlOVxUKrem19BUBUJL_J.W2PdBeL0Of.rOcP56TTW7ePf0.jlAtZ_pK4FEqVXgh6Dx7vfVzvu437OwF9huz_sLZLr6XkwdkiYC4FXm2V0jVvZTrYKDYANu8Rt2tejr6LDgtqvnNjbuVM27qT5IjCBsOLREL3yKBUm2wnFGFlN66giNVnqqkbn3ZSsfuXw--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A03A695.6050106@schaufler-ca.com>
Date: Thu, 07 May 2009 20:27:17 -0700
From: Casey Schaufler <casey@schaufler-ca.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Ingo Molnar <mingo@elte.hu>
CC: James Morris <jmorris@namei.org>, Chris Wright <chrisw@sous-sol.org>,
       Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       Al Viro <viro@ZenIV.linux.org.uk>,
       linux-security-module@vger.kernel.org
Subject: Re: your mail
References: <20090506235349.GC3756@redhat.com> <20090507002133.02D05FC39E@magilla.sf.frob.com> <20090507063606.GA15220@redhat.com> <20090507082027.GD12285@elte.hu> <20090507083102.GA20125@redhat.com> <20090507083851.GA19133@elte.hu> <20090507085742.GB3036@sequoia.sous-sol.org> <20090507090459.GE19133@elte.hu> <20090507092009.GC3036@sequoia.sous-sol.org> <alpine.LRH.2.00.0905071951530.29219@tundra.namei.org> <20090507102015.GB8901@elte.hu>
In-Reply-To: <20090507102015.GB8901@elte.hu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Ingo Molnar wrote:
> * James Morris <jmorris@namei.org> wrote:
>
>   
>> On Thu, 7 May 2009, Chris Wright wrote:
>>
>>     
>>> * Ingo Molnar (mingo@elte.hu) wrote:
>>>       
>> [Added LSM list to the CC; please do so whenever making changes in this 
>> area...]
>>
>>     
>>>> They have no active connection to the core kernel 
>>>> ptrace_may_access() check in any case:
>>>>         
>>> Not sure what you mean:
>>>
>>> ptrace_may_access
>>>  __ptrace_may_access
>>>   security_ptrace_may_access
>>>
>>> Looks like your patch won't compile.
>>>
>>>       
>> Below is an updated version which fixes the bug, against 
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>>
>> Boot tested with SELinux.
>>     
>
> thanks! Below are the two patches i wrote and tested.
>   

I hate to make an assumption regarding whether or not your tests
included Smack, so I'll ask. Does tested mean with Smack?

Thank you.

> 	Ingo
>
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:49:47 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
> 	ptrace_access_check
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> 	Andrew Morton <akpm@linux-foundation.org>,
> 	linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> The ptrace_may_access() methods are named confusingly - some 
> variants return a bool, while the security subsystem methods have a 
> retval convention.
>
> Rename it to ptrace_access_check, to reduce the confusion factor. A 
> followup patch eliminates the bool usage.
>
> [ Impact: cleanup, no code changed ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Cc: Roland McGrath <roland@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Chris Wright <chrisw@sous-sol.org>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Oleg Nesterov <oleg@redhat.com>
> LKML-Reference: <20090507084943.GB19133@elte.hu>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  fs/proc/array.c            |    2 +-
>  fs/proc/base.c             |   10 +++++-----
>  fs/proc/task_mmu.c         |    2 +-
>  include/linux/ptrace.h     |    4 ++--
>  include/linux/security.h   |   14 +++++++-------
>  kernel/ptrace.c            |   10 +++++-----
>  security/capability.c      |    2 +-
>  security/commoncap.c       |    4 ++--
>  security/root_plug.c       |    2 +-
>  security/security.c        |    4 ++--
>  security/selinux/hooks.c   |    6 +++---
>  security/smack/smack_lsm.c |    8 ++++----
>  12 files changed, 34 insertions(+), 34 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file 
>  
>  	state = *get_task_state(task);
>  	vsize = eip = esp = 0;
> -	permitted = ptrace_may_access(task, PTRACE_MODE_READ);
> +	permitted = ptrace_access_check(task, PTRACE_MODE_READ);
>  	mm = get_task_mm(task);
>  	if (mm) {
>  		vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
>  		rcu_read_lock();
>  		match = (tracehook_tracer_task(task) == current);
>  		rcu_read_unlock();
> -		if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
> +		if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
>  			return 0;
>  	}
>  
> @@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
>  	if (task->mm != mm)
>  		goto out;
>  	if (task->mm != current->mm &&
> -	    __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
> +	    __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
>  		goto out;
>  	task_unlock(task);
>  	return mm;
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
>  	wchan = get_wchan(task);
>  
>  	if (lookup_symbol_name(wchan, symname) < 0)
> -		if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +		if (!ptrace_access_check(task, PTRACE_MODE_READ))
>  			return 0;
>  		else
>  			return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
>  	 */
>  	task = get_proc_task(inode);
>  	if (task) {
> -		allowed = ptrace_may_access(task, PTRACE_MODE_READ);
> +		allowed = ptrace_access_check(task, PTRACE_MODE_READ);
>  		put_task_struct(task);
>  	}
>  	return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file 
>  	if (!task)
>  		goto out_no_task;
>  
> -	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +	if (!ptrace_access_check(task, PTRACE_MODE_READ))
>  		goto out;
>  
>  	ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file 
>  		goto out;
>  
>  	ret = -EACCES;
> -	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +	if (!ptrace_access_check(task, PTRACE_MODE_READ))
>  		goto out_task;
>  
>  	ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
>  #define PTRACE_MODE_READ   1
>  #define PTRACE_MODE_ATTACH 2
>  /* Returns 0 on success, -errno on denial. */
> -extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
>  /* Returns true on success, false on denial. */
> -extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
>  
>  static inline int ptrace_reparented(struct task_struct *child)
>  {
> Index: linux/include/linux/security.h
> ===================================================================
> --- linux.orig/include/linux/security.h
> +++ linux/include/linux/security.h
> @@ -52,7 +52,7 @@ struct audit_krule;
>  extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
>  		       int cap, int audit);
>  extern int cap_settime(struct timespec *ts, struct timezone *tz);
> -extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
>  extern int cap_ptrace_traceme(struct task_struct *parent);
>  extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
>  extern int cap_capset(struct cred *new, const struct cred *old,
> @@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
>   *	@alter contains the flag indicating whether changes are to be made.
>   *	Return 0 if permission is granted.
>   *
> - * @ptrace_may_access:
> + * @ptrace_access_check:
>   *	Check permission before allowing the current process to trace the
>   *	@child process.
>   *	Security modules may also want to perform a process tracing check
> @@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
>   *	Check that the @parent process has sufficient permission to trace the
>   *	current process before allowing the current process to present itself
>   *	to the @parent process for tracing.
> - *	The parent process will still have to undergo the ptrace_may_access
> + *	The parent process will still have to undergo the ptrace_access_check
>   *	checks before it is allowed to trace this one.
>   *	@parent contains the task_struct structure for debugger process.
>   *	Return 0 if permission is granted.
> @@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
>  struct security_operations {
>  	char name[SECURITY_NAME_MAX + 1];
>  
> -	int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
> +	int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
>  	int (*ptrace_traceme) (struct task_struct *parent);
>  	int (*capget) (struct task_struct *target,
>  		       kernel_cap_t *effective,
> @@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
>  extern int register_security(struct security_operations *ops);
>  
>  /* Security operations */
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
>  int security_ptrace_traceme(struct task_struct *parent);
>  int security_capget(struct task_struct *target,
>  		    kernel_cap_t *effective,
> @@ -1798,10 +1798,10 @@ static inline int security_init(void)
>  	return 0;
>  }
>  
> -static inline int security_ptrace_may_access(struct task_struct *child,
> +static inline int security_ptrace_access_check(struct task_struct *child,
>  					     unsigned int mode)
>  {
> -	return cap_ptrace_may_access(child, mode);
> +	return cap_ptrace_access_check(child, mode);
>  }
>  
>  static inline int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
>  	return ret;
>  }
>  
> -int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +int __ptrace_access_check(struct task_struct *task, unsigned int mode)
>  {
>  	const struct cred *cred = current_cred(), *tcred;
>  
> @@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
>  	if (!dumpable && !capable(CAP_SYS_PTRACE))
>  		return -EPERM;
>  
> -	return security_ptrace_may_access(task, mode);
> +	return security_ptrace_access_check(task, mode);
>  }
>  
> -bool ptrace_may_access(struct task_struct *task, unsigned int mode)
> +bool ptrace_access_check(struct task_struct *task, unsigned int mode)
>  {
>  	int err;
>  	task_lock(task);
> -	err = __ptrace_may_access(task, mode);
> +	err = __ptrace_access_check(task, mode);
>  	task_unlock(task);
>  	return !err;
>  }
> @@ -217,7 +217,7 @@ repeat:
>  	/* the same process cannot be attached many times */
>  	if (task->ptrace & PT_PTRACED)
>  		goto bad;
> -	retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
> +	retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
>  	if (retval)
>  		goto bad;
>  
> Index: linux/security/capability.c
> ===================================================================
> --- linux.orig/security/capability.c
> +++ linux/security/capability.c
> @@ -863,7 +863,7 @@ struct security_operations default_secur
>  
>  void security_fixup_ops(struct security_operations *ops)
>  {
> -	set_to_cap_if_null(ops, ptrace_may_access);
> +	set_to_cap_if_null(ops, ptrace_access_check);
>  	set_to_cap_if_null(ops, ptrace_traceme);
>  	set_to_cap_if_null(ops, capget);
>  	set_to_cap_if_null(ops, capset);
> Index: linux/security/commoncap.c
> ===================================================================
> --- linux.orig/security/commoncap.c
> +++ linux/security/commoncap.c
> @@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
>  }
>  
>  /**
> - * cap_ptrace_may_access - Determine whether the current process may access
> + * cap_ptrace_access_check - Determine whether the current process may access
>   *			   another
>   * @child: The process to be accessed
>   * @mode: The mode of attachment.
> @@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
>   * Determine whether a process may access another, returning 0 if permission
>   * granted, -ve if denied.
>   */
> -int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
>  {
>  	int ret = 0;
>  
> Index: linux/security/root_plug.c
> ===================================================================
> --- linux.orig/security/root_plug.c
> +++ linux/security/root_plug.c
> @@ -72,7 +72,7 @@ static int rootplug_bprm_check_security 
>  
>  static struct security_operations rootplug_security_ops = {
>  	/* Use the capability functions for some of the hooks */
> -	.ptrace_may_access =		cap_ptrace_may_access,
> +	.ptrace_access_check =		cap_ptrace_access_check,
>  	.ptrace_traceme =		cap_ptrace_traceme,
>  	.capget =			cap_capget,
>  	.capset =			cap_capset,
> Index: linux/security/security.c
> ===================================================================
> --- linux.orig/security/security.c
> +++ linux/security/security.c
> @@ -127,9 +127,9 @@ int register_security(struct security_op
>  
>  /* Security operations */
>  
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
>  {
> -	return security_ops->ptrace_may_access(child, mode);
> +	return security_ops->ptrace_access_check(child, mode);
>  }
>  
>  int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/security/selinux/hooks.c
> ===================================================================
> --- linux.orig/security/selinux/hooks.c
> +++ linux/security/selinux/hooks.c
> @@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
>  
>  /* Hook functions begin here. */
>  
> -static int selinux_ptrace_may_access(struct task_struct *child,
> +static int selinux_ptrace_access_check(struct task_struct *child,
>  				     unsigned int mode)
>  {
>  	int rc;
>  
> -	rc = cap_ptrace_may_access(child, mode);
> +	rc = cap_ptrace_access_check(child, mode);
>  	if (rc)
>  		return rc;
>  
> @@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
>  static struct security_operations selinux_ops = {
>  	.name =				"selinux",
>  
> -	.ptrace_may_access =		selinux_ptrace_may_access,
> +	.ptrace_access_check =		selinux_ptrace_access_check,
>  	.ptrace_traceme =		selinux_ptrace_traceme,
>  	.capget =			selinux_capget,
>  	.capset =			selinux_capset,
> Index: linux/security/smack/smack_lsm.c
> ===================================================================
> --- linux.orig/security/smack/smack_lsm.c
> +++ linux/security/smack/smack_lsm.c
> @@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
>   */
>  
>  /**
> - * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
> + * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
>   * @ctp: child task pointer
>   * @mode: ptrace attachment mode
>   *
> @@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
>   *
>   * Do the capability checks, and require read and write.
>   */
> -static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
> +static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
>  {
>  	int rc;
>  
> -	rc = cap_ptrace_may_access(ctp, mode);
> +	rc = cap_ptrace_access_check(ctp, mode);
>  	if (rc != 0)
>  		return rc;
>  
> @@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
>  struct security_operations smack_ops = {
>  	.name =				"smack",
>  
> -	.ptrace_may_access =		smack_ptrace_may_access,
> +	.ptrace_access_check =		smack_ptrace_access_check,
>  	.ptrace_traceme =		smack_ptrace_traceme,
>  	.capget = 			cap_capget,
>  	.capset = 			cap_capset,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:50:54 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
> 	function
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> 	Andrew Morton <akpm@linux-foundation.org>,
> 	linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> ptrace_access_check() returns a bool, while most of the ptrace 
> access check machinery works with Linux retvals (where 0 indicates 
> success, negative indicates an error).
>
> So eliminate the bool and invert the usage at the call sites.
>
> ( Note: "< 0" checks are used instead of !0 checks, because that's
>   the convention for retval checks and it results in similarly fast
>   assembly code. )
>
> [ Impact: cleanup ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  fs/proc/array.c        |    2 +-
>  fs/proc/base.c         |    8 ++++----
>  fs/proc/task_mmu.c     |    2 +-
>  include/linux/ptrace.h |    2 +-
>  kernel/ptrace.c        |    6 ++++--
>  5 files changed, 11 insertions(+), 9 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file 
>  
>  	state = *get_task_state(task);
>  	vsize = eip = esp = 0;
> -	permitted = ptrace_access_check(task, PTRACE_MODE_READ);
> +	permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
>  	mm = get_task_mm(task);
>  	if (mm) {
>  		vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
>  		rcu_read_lock();
>  		match = (tracehook_tracer_task(task) == current);
>  		rcu_read_unlock();
> -		if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
> +		if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
>  			return 0;
>  	}
>  
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
>  	wchan = get_wchan(task);
>  
>  	if (lookup_symbol_name(wchan, symname) < 0)
> -		if (!ptrace_access_check(task, PTRACE_MODE_READ))
> +		if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
>  			return 0;
>  		else
>  			return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
>  	 */
>  	task = get_proc_task(inode);
>  	if (task) {
> -		allowed = ptrace_access_check(task, PTRACE_MODE_READ);
> +		allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
>  		put_task_struct(task);
>  	}
>  	return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file 
>  	if (!task)
>  		goto out_no_task;
>  
> -	if (!ptrace_access_check(task, PTRACE_MODE_READ))
> +	if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
>  		goto out;
>  
>  	ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file 
>  		goto out;
>  
>  	ret = -EACCES;
> -	if (!ptrace_access_check(task, PTRACE_MODE_READ))
> +	if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
>  		goto out_task;
>  
>  	ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
>  /* Returns 0 on success, -errno on denial. */
>  extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
>  /* Returns true on success, false on denial. */
> -extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
> +extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
>  
>  static inline int ptrace_reparented(struct task_struct *child)
>  {
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
>  	return security_ptrace_access_check(task, mode);
>  }
>  
> -bool ptrace_access_check(struct task_struct *task, unsigned int mode)
> +int ptrace_access_check(struct task_struct *task, unsigned int mode)
>  {
>  	int err;
> +
>  	task_lock(task);
>  	err = __ptrace_access_check(task, mode);
>  	task_unlock(task);
> -	return !err;
> +
> +	return err;
>  }
>  
>  int ptrace_attach(struct task_struct *task)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753883Ab0FRXzr (ORCPT <rfc822;w@1wt.eu>);
	Fri, 18 Jun 2010 19:55:47 -0400
Received: from kroah.org ([198.145.64.141]:42027 "EHLO coco.kroah.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753682Ab0FRXzq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 18 Jun 2010 19:55:46 -0400
Date: Fri, 18 Jun 2010 16:52:42 -0700
From: Greg KH <greg@kroah.com>
To: Mike Gilks <mike.kernel@gilksonline.com>
Cc: gregkh@suse.de, mchehab@redhat.com, julia@diku.dk, joe@perches.com,
       devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20100618235242.GA1128@kroah.com>
References: <1276409811-16682-1-git-send-email-mike.kernel@gilksonline.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1276409811-16682-1-git-send-email-mike.kernel@gilksonline.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Jun 13, 2010 at 02:16:47PM +0800, Mike Gilks wrote:
> Subject:r8192U_core.c Last pass
> In-Reply-To: 
> 
> 
> This is the last patch I can manage for this file.
> Everything else to do with checkpatch.pl issues may require an actual developer to look at it.

I have a whole bunch of series of patches from you (one duplicating
Linus's patch, I don't think you ment to send that...)  So, which should
I apply?

How about I delete them all and you send me the latest ones that you
want me to apply, as I'm totally confused which is your latest version
and which isn't and I see lots of duplicates.

Sound good?

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755504Ab1ACRDr (ORCPT <rfc822;w@1wt.eu>);
	Mon, 3 Jan 2011 12:03:47 -0500
Received: from mx1.redhat.com ([209.132.183.28]:35867 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753674Ab1ACRDp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 3 Jan 2011 12:03:45 -0500
Date: Mon, 3 Jan 2011 18:03:17 +0100
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: castet.matthieu@free.fr
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, stf_xl@wp.pl,
        tj@kernel.org
Subject: Re: your mail
Message-ID: <20110103170308.GA2285@redhat.com>
References: <1294072680.4d21fb68cbdcf@imp.free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1294072680.4d21fb68cbdcf@imp.free.fr>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> Hi,
> 
> could you CC me on ueagle-atm.c patches.
> 
> From what I remind we sleep in the workqueue, that's why we couldn't use the
> system one (freeze keyboard...). But may be the code changed.
In case when firmware is not available we can sleep for a few seconds in
work function. That's block keyboard driver who also use common workqueue.
If recent Tejun workqueue rewrite allow to long sleep in work func and
not hurt other workqueue users, patch is ok.

Unfortunately I'm not able to test the patch, my ueagle device was physically
damaged a few months ago.

Stanislaw

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751384Ab1ADFSE (ORCPT <rfc822;w@1wt.eu>);
	Tue, 4 Jan 2011 00:18:04 -0500
Received: from mail-ey0-f194.google.com ([209.85.215.194]:43379 "EHLO
	mail-ey0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750779Ab1ADFSC (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Jan 2011 00:18:02 -0500
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=Ma4xj67tyNuv0rpOwQOIk3MYpL+y1HT9KY9WlrhhKfcOFW87gFBhhbegSvT4w/I2IF
         SPPOtDvHe01cdoWqA+fvvPIWZp8N7BArVmWxZWGEm4CXZCJ4TfPRxMR0BtqHFH3dDPWD
         I+4DcgZEJALRBw5t27cKZwprkL5/MrnP1UU9A=
Date: Tue, 4 Jan 2011 06:17:51 +0100
From: Tejun Heo <tj@kernel.org>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: castet.matthieu@free.fr, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org, stf_xl@wp.pl
Subject: Re: your mail
Message-ID: <20110104051751.GB6748@mtj.dyndns.org>
References: <1294072680.4d21fb68cbdcf@imp.free.fr>
 <20110103170308.GA2285@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110103170308.GA2285@redhat.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 03, 2011 at 06:03:17PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> > could you CC me on ueagle-atm.c patches.

Will try to, but maybe it's a good idea to add a MAINTAINERS entry?

> > From what I remind we sleep in the workqueue, that's why we couldn't use the
> > system one (freeze keyboard...). But may be the code changed.
> In case when firmware is not available we can sleep for a few seconds in
> work function. That's block keyboard driver who also use common workqueue.
> If recent Tejun workqueue rewrite allow to long sleep in work func and
> not hurt other workqueue users, patch is ok.

Yeap, work items can sleep all they want on the system_wq.  It won't
delay execution of other work items.

Thanks.

--
tejun

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756887Ab1ANEld (ORCPT <rfc822;w@1wt.eu>);
	Thu, 13 Jan 2011 23:41:33 -0500
Received: from cantor2.suse.de ([195.135.220.15]:39686 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756691Ab1ANEl0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 13 Jan 2011 23:41:26 -0500
Date: Thu, 13 Jan 2011 20:36:19 -0800
From: Greg KH <gregkh@suse.de>
To: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>, devel@driverdev.osuosl.org,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20110114043619.GA5770@suse.de>
References: <1294967693-1938-1-git-send-email-omar.ramirez@ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1294967693-1938-1-git-send-email-omar.ramirez@ti.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jan 13, 2011 at 07:14:53PM -0600, Omar Ramirez Luna wrote:
> Please pull these changes for 2.6.38:
> 
> The following changes since commit 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5:
> 
>   Linux 2.6.37 (2011-01-04 16:50:19 -0800)
> 
> are available in the git repository at:
>   git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git for-gkh-2.6.38
> 
> Guzman Lugo, Fernando (1):
>       staging: tidspbridge: configure full L1 MMU range
> 
> Omar Ramirez Luna (1):
>       staging: tidspbridge: replace mbox callback with notifier_call
> 
>  drivers/staging/tidspbridge/core/tiomap3430.c |   15 +++++++--------
>  1 files changed, 7 insertions(+), 8 deletions(-)

You forgot a Subject: line.

Also, as these are just 2 patches, care to just email them so we can
review them?

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752938Ab1IZXXv (ORCPT <rfc822;w@1wt.eu>);
	Mon, 26 Sep 2011 19:23:51 -0400
Received: from out4.smtp.messagingengine.com ([66.111.4.28]:34258 "EHLO
	out4.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752743Ab1IZXXu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 26 Sep 2011 19:23:50 -0400
X-Sasl-enc: 2+hFHs1bj4kuc2aDsZJpazFH8cTgE5XQBBKOLpY8Xmxf 1317079429
Date: Mon, 26 Sep 2011 16:23:25 -0700
From: Greg KH <greg@kroah.com>
To: jim.cromie@gmail.com
Cc: jbaron@redhat.com, joe@perches.com, bart.vanassche@gmail.com,
        linux-kernel@vger.kernel.org
Subject: Re: your mail
Message-ID: <20110926232325.GA15849@kroah.com>
References: <1316642115-20029-1-git-send-email-jim.cromie@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1316642115-20029-1-git-send-email-jim.cromie@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 21, 2011 at 03:54:49PM -0600, jim.cromie@gmail.com wrote:
> hi all,
> 
> this reworked* patchset enhances dynamic-debug with:

I need acks from Jason before I can apply any of this...


From mboxrd@z Thu Jan  1 00:00:00 1970
From: ynorov@caviumnetworks.com (Yury Norov)
Date: Wed, 14 Jun 2017 23:16:11 +0300
Subject: your mail
In-Reply-To: <20170604120009.342-1-ynorov@caviumnetworks.com>
References: <20170604120009.342-1-ynorov@caviumnetworks.com>
Message-ID: <20170614201611.skc6k26nmnc254vw@yury-thinkpad>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Hi Catalin, all.

Thank you for your time on reviewing the series. I really appreciate it.

This is the updated version where I tried to address all comments:
https://github.com/norov/linux/commits/ilp32-20170613.4

(3 last patches here is the Andrew Pinski's rework of vdso rebased on
ilp32 series)

If nothing will come here on review, I'll send v8 at the beginning of
the next week. Is this plan OK?

And this is the backport on the v4.11 kernel:
https://github.com/norov/linux/commits/ilp32-4.11.4

Yury

On Sun, Jun 04, 2017 at 02:59:49PM +0300, Yury Norov wrote:
> Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
> 
> Hi Catalin,
>  
> Here is a rebase of latest kernel patchset against next-20170602. There's almost
> no changes, but there are some conflicts that are not trivial, and I'd like to
> refresh the submission therefore.
> 
> How are your experiments with testing and benchmarking of ILP32 are going? In
> my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
> LMBench shows no difference for LP64 and expected performance boost for ILP32
> (compared to LP64 results).
> 
> Steve Ellcey is handling upstream submission of Glibc patches. The patches are
> ready and have been reviewed and reworked per community?s comments. There are
> no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
> on ILP32 kernel submission.
> 
> Catalin, regarding rootfs, is OpenSuSe?s build sufficient for your experiments?
> I?ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
> them to Debian.
> 
> One last thing I wanted to check with you about is ILP32 PCS - does, in your
> view, ARM Ltd. needs to publish any additional docs for ABI to become official?
> 
> Below is the regular description.
> 
> Thanks.
> Yury
> 
> --------
> 
> This series enables aarch64 with ilp32 mode.
> 
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t is is used by new userspace). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
> 
> This version is based on linux-next from 2017-03-01. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
> 
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
> 
> This is the rebase of v7 - still no major changes has been made.
> 
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-20170602
> https://github.com/norov/glibc/tree/dev9
> 
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
> 
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap:  https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: https://lkml.org/lkml/2017/1/9/213
> v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
> v7: Resend 2:
>     - vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
>     - rebased on next-20170602.
> 
> Andrew Pinski (6):
>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>   arm64: ensure the kernel is compiled for LP64
>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
>     it
>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
>     ucontext
>   arm64:ilp32: add ARM64_ILP32 to Kconfig
> 
> Philipp Tomsich (1):
>   arm64:ilp32: add vdso-ilp32 and use for signal return
> 
> Yury Norov (13):
>   compat ABI: use non-compat openat and open_by_handle_at variants
>   32-bit ABI: introduce ARCH_32BIT_OFF_T config option
>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>   thread: move thread bits accessors to separated file
>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>   arm64: introduce binfmt_elf32.c
>   arm64: ilp32: introduce binfmt_ilp32.c
>   arm64: ilp32: share aarch32 syscall handlers
>   arm64: signal: share lp64 signal routines to ilp32
>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
> 
>  Documentation/arm64/ilp32.txt                 |  45 +++++++
>  arch/Kconfig                                  |   4 +
>  arch/arc/Kconfig                              |   1 +
>  arch/arc/include/uapi/asm/unistd.h            |   1 +
>  arch/arm/Kconfig                              |   1 +
>  arch/arm64/Kconfig                            |  19 ++-
>  arch/arm64/Makefile                           |   8 ++
>  arch/arm64/include/asm/compat.h               |  19 +--
>  arch/arm64/include/asm/elf.h                  |  37 ++----
>  arch/arm64/include/asm/fpsimd.h               |   2 +-
>  arch/arm64/include/asm/ftrace.h               |   2 +-
>  arch/arm64/include/asm/hwcap.h                |   6 +-
>  arch/arm64/include/asm/is_compat.h            |  90 ++++++++++++++
>  arch/arm64/include/asm/memory.h               |   5 +-
>  arch/arm64/include/asm/processor.h            |  11 +-
>  arch/arm64/include/asm/ptrace.h               |   2 +-
>  arch/arm64/include/asm/seccomp.h              |   2 +-
>  arch/arm64/include/asm/signal32.h             |   9 +-
>  arch/arm64/include/asm/signal32_common.h      |  27 ++++
>  arch/arm64/include/asm/signal_common.h        |  33 +++++
>  arch/arm64/include/asm/signal_ilp32.h         |  38 ++++++
>  arch/arm64/include/asm/syscall.h              |   2 +-
>  arch/arm64/include/asm/thread_info.h          |   4 +-
>  arch/arm64/include/asm/unistd.h               |   6 +-
>  arch/arm64/include/asm/vdso.h                 |   6 +
>  arch/arm64/include/uapi/asm/bitsperlong.h     |   9 +-
>  arch/arm64/include/uapi/asm/unistd.h          |  13 ++
>  arch/arm64/kernel/Makefile                    |   8 +-
>  arch/arm64/kernel/asm-offsets.c               |   9 +-
>  arch/arm64/kernel/binfmt_elf32.c              |  38 ++++++
>  arch/arm64/kernel/binfmt_ilp32.c              |  85 +++++++++++++
>  arch/arm64/kernel/cpufeature.c                |   8 +-
>  arch/arm64/kernel/cpuinfo.c                   |  20 +--
>  arch/arm64/kernel/entry.S                     |  34 +++++-
>  arch/arm64/kernel/entry32.S                   |  80 ------------
>  arch/arm64/kernel/entry32_common.S            | 107 ++++++++++++++++
>  arch/arm64/kernel/entry_ilp32.S               |  22 ++++
>  arch/arm64/kernel/head.S                      |   2 +-
>  arch/arm64/kernel/hw_breakpoint.c             |   8 +-
>  arch/arm64/kernel/perf_regs.c                 |   2 +-
>  arch/arm64/kernel/process.c                   |   7 +-
>  arch/arm64/kernel/ptrace.c                    |  80 ++++++++++--
>  arch/arm64/kernel/signal.c                    | 102 ++++++++++------
>  arch/arm64/kernel/signal32.c                  | 107 ----------------
>  arch/arm64/kernel/signal32_common.c           | 135 ++++++++++++++++++++
>  arch/arm64/kernel/signal_ilp32.c              | 170 ++++++++++++++++++++++++++
>  arch/arm64/kernel/sys_ilp32.c                 | 100 +++++++++++++++
>  arch/arm64/kernel/traps.c                     |   5 +-
>  arch/arm64/kernel/vdso-ilp32/.gitignore       |   2 +
>  arch/arm64/kernel/vdso-ilp32/Makefile         |  80 ++++++++++++
>  arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S     |  33 +++++
>  arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S |  95 ++++++++++++++
>  arch/arm64/kernel/vdso.c                      |  69 +++++++++--
>  arch/arm64/kernel/vdso/gettimeofday.S         |  20 ++-
>  arch/arm64/kernel/vdso/vdso.S                 |   6 +-
>  arch/blackfin/Kconfig                         |   1 +
>  arch/c6x/include/uapi/asm/unistd.h            |   1 +
>  arch/cris/Kconfig                             |   1 +
>  arch/frv/Kconfig                              |   1 +
>  arch/h8300/Kconfig                            |   1 +
>  arch/h8300/include/uapi/asm/unistd.h          |   1 +
>  arch/hexagon/Kconfig                          |   1 +
>  arch/hexagon/include/uapi/asm/unistd.h        |   1 +
>  arch/m32r/Kconfig                             |   1 +
>  arch/m68k/Kconfig                             |   1 +
>  arch/metag/Kconfig                            |   1 +
>  arch/metag/include/uapi/asm/unistd.h          |   1 +
>  arch/microblaze/Kconfig                       |   1 +
>  arch/mips/Kconfig                             |   1 +
>  arch/mn10300/Kconfig                          |   1 +
>  arch/nios2/Kconfig                            |   1 +
>  arch/nios2/include/uapi/asm/unistd.h          |   1 +
>  arch/openrisc/Kconfig                         |   1 +
>  arch/openrisc/include/uapi/asm/unistd.h       |   1 +
>  arch/parisc/Kconfig                           |   1 +
>  arch/powerpc/Kconfig                          |   1 +
>  arch/score/Kconfig                            |   1 +
>  arch/score/include/uapi/asm/unistd.h          |   1 +
>  arch/sh/Kconfig                               |   1 +
>  arch/sparc/Kconfig                            |   1 +
>  arch/tile/Kconfig                             |   1 +
>  arch/tile/include/uapi/asm/unistd.h           |   1 +
>  arch/tile/kernel/compat.c                     |   3 +
>  arch/unicore32/Kconfig                        |   1 +
>  arch/unicore32/include/uapi/asm/unistd.h      |   1 +
>  arch/x86/Kconfig                              |   1 +
>  arch/x86/um/Kconfig                           |   1 +
>  arch/xtensa/Kconfig                           |   1 +
>  drivers/clocksource/arm_arch_timer.c          |   2 +-
>  include/linux/fcntl.h                         |   2 +-
>  include/linux/thread_bits.h                   |  63 ++++++++++
>  include/linux/thread_info.h                   |  66 ++--------
>  include/uapi/asm-generic/unistd.h             |  10 +-
>  93 files changed, 1601 insertions(+), 413 deletions(-)
>  create mode 100644 Documentation/arm64/ilp32.txt
>  create mode 100644 arch/arm64/include/asm/is_compat.h
>  create mode 100644 arch/arm64/include/asm/signal32_common.h
>  create mode 100644 arch/arm64/include/asm/signal_common.h
>  create mode 100644 arch/arm64/include/asm/signal_ilp32.h
>  create mode 100644 arch/arm64/kernel/binfmt_elf32.c
>  create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
>  create mode 100644 arch/arm64/kernel/entry32_common.S
>  create mode 100644 arch/arm64/kernel/entry_ilp32.S
>  create mode 100644 arch/arm64/kernel/signal32_common.c
>  create mode 100644 arch/arm64/kernel/signal_ilp32.c
>  create mode 100644 arch/arm64/kernel/sys_ilp32.c
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
>  create mode 100644 include/linux/thread_bits.h
> 
> -- 
> 2.11.0

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=L6H7=YT=lists.infradead.org=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 24F03CA9EB9
	for <infradead-linux-arm-kernel@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:28 +0000 (UTC)
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id C21FA20863
	for <infradead-linux-arm-kernel@archiver.kernel.org>; Sat, 26 Oct 2019 19:30:27 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VxxVVQCi";
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hi2r2tM6"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C21FA20863
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=bombadil.20170209; h=Sender:
	Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:
	List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:
	Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	List-Owner; bh=X4mB5Y15U10CLLRuWyLo64c/jLOfD9IG/U+9FibRHpY=; b=VxxVVQCi8QWk6P
	74AK6HjOpII/LBbnmcxQ+NjkxiLR8SU0MoOnjQcDATNPO0d29mKAYnc0nECT7MkklJJ90LqE1vwFO
	ms2o3RsS5XnDGaa1LvGAepnfShaEfdAaS/B5L29n2B+6aXw7VnGAyYsLgri+T0RKW4S4q758p7LeL
	osmKNjN7G2Wq9G6D6voWLJ/jamy3MKi0+QGG8D/U6TuYBhokCUYFt1dRw97/eZUbESXA4j06uOshG
	7fZx7LXq9XDYb3fhuXrOEQ7V+5ISWrQTPFmS23Uwc9m+1onA5qJJbbAcx3qedOGjVxEBPhJo+3tBY
	j/D3fuDDUyrRkJuZEVug==;
Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org)
	by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux))
	id 1iORla-0000zq-Ja; Sat, 26 Oct 2019 19:30:26 +0000
Received: from mail.kernel.org ([198.145.29.99])
 by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux))
 id 1iORlW-0000zL-Ra; Sat, 26 Oct 2019 19:30:24 +0000
Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl
 [83.86.89.107])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.kernel.org (Postfix) with ESMTPSA id 9081D20863;
 Sat, 26 Oct 2019 19:30:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
 s=default; t=1572118221;
 bh=1vWJNlJ9nmxdq2/TYTJ8H4g9od0RudmBwjhdidF/U3A=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=Hi2r2tM6TywiRAJPIiqblSIrVQlGBlYTNlHn/wq31sE5yhsBzHjW7cjrmAnMCq5AX
 amDA7DsHIXtCXm0xWGwyuIDNV/ta6Tivu3T9wVbhYe7ou371SsYBOGPq0tR7qgzHM6
 paQ0mVgIjrcv6ecZPQNeoZaEYDzKQRQIoq55wABA=
Date: Sat, 26 Oct 2019 21:30:18 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Frank Wunderlich <frank-w@public-files.de>
Subject: Re: your mail
Message-ID: <20191026193018.GA812200@kroah.com>
References: <20191026192359.27687-1-frank-w@public-files.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20191026192359.27687-1-frank-w@public-files.de>
User-Agent: Mutt/1.12.2 (2019-09-21)
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20191026_123022_925685_3D657AAC 
X-CRM114-Status: UNSURE (   6.24  )
X-CRM114-Notice: Please train this message.
X-BeenThere: linux-arm-kernel@lists.infradead.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <linux-arm-kernel.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
 linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
 linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org

On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one

Odd email with no subject line :(

Plaese fix up and resend.

thanks,

greg k-h-

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Elfyn McBratney <beu@gentoo.org>
Subject: Re: your mail
Date: Thu, 6 Oct 2005 11:52:10 +0100
Message-ID: <20051006105210.GA3131@gentoo.org>
References: <11E379B4363F884A913C18A99C40976D1F4F35@simmail.adsintranet.corp>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg"
Cc: Willem Swart <willems@adsmr.co.za>
X-From: git-owner@vger.kernel.org Thu Oct 06 12:52:34 2005
Return-path: <git-owner@vger.kernel.org>
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1ENTMT-0002Bi-3l
	for gcvg-git@gmane.org; Thu, 06 Oct 2005 12:52:29 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750778AbVJFKwU (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Thu, 6 Oct 2005 06:52:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750789AbVJFKwU
	(ORCPT <rfc822;git-outgoing>); Thu, 6 Oct 2005 06:52:20 -0400
Received: from anchor-post-33.mail.demon.net ([194.217.242.91]:16133 "EHLO
	anchor-post-33.mail.demon.net") by vger.kernel.org with ESMTP
	id S1750778AbVJFKwT (ORCPT <rfc822;git@vger.kernel.org>);
	Thu, 6 Oct 2005 06:52:19 -0400
Received: from beu1.demon.co.uk ([83.105.51.149] helo=zippy.emcb.local)
	by anchor-post-33.mail.demon.net with esmtp (Exim 4.42)
	id 1ENTMB-000EuI-BI; Thu, 06 Oct 2005 10:52:16 +0000
Received: by zippy.emcb.local (Postfix, from userid 1001)
	id CA5BE148040; Thu,  6 Oct 2005 11:52:10 +0100 (BST)
To: git@vger.kernel.org
Mail-Followup-To: Elfyn McBratney <beu@gentoo.org>, git@vger.kernel.org,
	Willem Swart <willems@adsmr.co.za>
Content-Disposition: inline
In-Reply-To: <11E379B4363F884A913C18A99C40976D1F4F35@simmail.adsintranet.corp>
Organisation: Gentoo Foundation, Inc.
User-Agent: mutt-ng/devel (Linux)
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/9767>


--gKMricLos+KVdGMg
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 05, 2005 at 08:10:24AM +0200, Willem Swart wrote:
 > subscribe git
 > -
 > To unsubscribe from this list: send the line "unsubscribe git" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
s/unsubscribe/subscribe/g

Might want to re-send that to majordomo@vger.kernel.org ;)

Best,
Elfyn

--=20
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

--gKMricLos+KVdGMg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRQHajUHll2nfF60RAs1pAKDFUR1iIHNUWDNlNtXPrMFpSsaKwACeNzhs
IzRfE9fgdrIwjU77t2yBMow=
=93+p
-----END PGP SIGNATURE-----

--gKMricLos+KVdGMg--

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: your mail
Date: Sun, 21 May 2006 19:55:14 -0400
Message-ID: <20060521235514.GC23096@fieldses.org>
References: <1148255528.61d5d241.0@fieldses.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: git@vger.kernel.org
X-From: git-owner@vger.kernel.org Mon May 22 01:55:23 2006
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1FhxlX-0000Ij-Nt
	for gcvg-git@gmane.org; Mon, 22 May 2006 01:55:20 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S964961AbWEUXzQ (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Sun, 21 May 2006 19:55:16 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964962AbWEUXzQ
	(ORCPT <rfc822;git-outgoing>); Sun, 21 May 2006 19:55:16 -0400
Received: from mail.fieldses.org ([66.93.2.214]:32425 "EHLO
	pickle.fieldses.org") by vger.kernel.org with ESMTP id S964961AbWEUXzP
	(ORCPT <rfc822;git@vger.kernel.org>);
	Sun, 21 May 2006 19:55:15 -0400
Received: from bfields by pickle.fieldses.org with local (Exim 4.62)
	(envelope-from <bfields@fieldses.org>)
	id 1FhxlS-0000VF-AJ; Sun, 21 May 2006 19:55:14 -0400
To: Junio C Hamano <junkio@cox.net>
Content-Disposition: inline
In-Reply-To: <1148255528.61d5d241.0@fieldses.org>
User-Agent: Mutt/1.5.11+cvs20060403
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/20469>

On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>

Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....

--b.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Junio C Hamano <junkio@cox.net>
Subject: Re: your mail
Date: Sun, 21 May 2006 17:16:44 -0700
Message-ID: <7vk68ehq1f.fsf@assigned-by-dhcp.cox.net>
References: <1148255528.61d5d241.0@fieldses.org>
	<20060521235514.GC23096@fieldses.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: git@vger.kernel.org
X-From: git-owner@vger.kernel.org Mon May 22 02:16:51 2006
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1Fhy6M-0002oj-8S
	for gcvg-git@gmane.org; Mon, 22 May 2006 02:16:50 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S964963AbWEVAQq (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Sun, 21 May 2006 20:16:46 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964960AbWEVAQq
	(ORCPT <rfc822;git-outgoing>); Sun, 21 May 2006 20:16:46 -0400
Received: from fed1rmmtao04.cox.net ([68.230.241.35]:25495 "EHLO
	fed1rmmtao04.cox.net") by vger.kernel.org with ESMTP
	id S964963AbWEVAQp (ORCPT <rfc822;git@vger.kernel.org>);
	Sun, 21 May 2006 20:16:45 -0400
Received: from assigned-by-dhcp.cox.net ([68.4.9.127])
          by fed1rmmtao04.cox.net
          (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP
          id <20060522001645.EWYG17501.fed1rmmtao04.cox.net@assigned-by-dhcp.cox.net>;
          Sun, 21 May 2006 20:16:45 -0400
To: "J. Bruce Fields" <bfields@fieldses.org>
In-Reply-To: <20060521235514.GC23096@fieldses.org> (J. Bruce Fields's message
	of "Sun, 21 May 2006 19:55:14 -0400")
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/20470>

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....

That's OK.  I just cooked up this one ;-).

-- >8 --
>From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body

Sometimes people just include the whole format-patch output in
the commit e-mail.  Detect it and skip the bogus ">From " line.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 mailinfo.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
 #define SEEN_FROM 01
 #define SEEN_DATE 02
 #define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
 
 /* First lines of body can have From:, Date:, and Subject: */
 static int handle_inbody_header(int *seen, char *line)
 {
+	if (!memcmp(">From", line, 5) && isspace(line[5])) {
+		if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+			*seen |= SEEN_BOGUS_UNIX_FROM;
+			return 1;
+		}
+	}
 	if (!memcmp("From:", line, 5) && isspace(line[5])) {
 		if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
 			*seen |= SEEN_FROM;
-- 
1.3.3.g292f

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: your mail
Date: Sun, 21 May 2006 21:33:15 -0400
Message-ID: <20060522013315.GC4818@fieldses.org>
References: <1148255528.61d5d241.0@fieldses.org> <20060521235514.GC23096@fieldses.org> <7vk68ehq1f.fsf@assigned-by-dhcp.cox.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: git@vger.kernel.org
X-From: git-owner@vger.kernel.org Mon May 22 03:33:22 2006
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1FhzIN-0004jS-QJ
	for gcvg-git@gmane.org; Mon, 22 May 2006 03:33:20 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932404AbWEVBdR (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Sun, 21 May 2006 21:33:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932420AbWEVBdR
	(ORCPT <rfc822;git-outgoing>); Sun, 21 May 2006 21:33:17 -0400
Received: from mail.fieldses.org ([66.93.2.214]:36761 "EHLO
	pickle.fieldses.org") by vger.kernel.org with ESMTP id S932404AbWEVBdQ
	(ORCPT <rfc822;git@vger.kernel.org>);
	Sun, 21 May 2006 21:33:16 -0400
Received: from bfields by pickle.fieldses.org with local (Exim 4.62)
	(envelope-from <bfields@fieldses.org>)
	id 1FhzIJ-0001zy-T5; Sun, 21 May 2006 21:33:15 -0400
To: Junio C Hamano <junkio@cox.net>
Content-Disposition: inline
In-Reply-To: <7vk68ehq1f.fsf@assigned-by-dhcp.cox.net>
User-Agent: Mutt/1.5.11+cvs20060403
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/20474>

On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
> 
> That's OK.  I just cooked up this one ;-).

Thanks!--b.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: your mail
Date: Tue, 26 Sep 2006 12:56:38 -0700 (PDT)
Message-ID: <Pine.LNX.4.64.0609261249310.3952@g5.osdl.org>
References: <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Andy Whitcroft <apw@shadowen.org>,
	Git Mailing List <git@vger.kernel.org>
X-From: git-owner@vger.kernel.org Tue Sep 26 21:57:59 2006
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1GSJ2u-0001SC-8T
	for gcvg-git@gmane.org; Tue, 26 Sep 2006 21:56:48 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932258AbWIZT4p (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Tue, 26 Sep 2006 15:56:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932257AbWIZT4p
	(ORCPT <rfc822;git-outgoing>); Tue, 26 Sep 2006 15:56:45 -0400
Received: from smtp.osdl.org ([65.172.181.4]:51922 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S932258AbWIZT4o (ORCPT
	<rfc822;git@vger.kernel.org>); Tue, 26 Sep 2006 15:56:44 -0400
Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6])
	by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id k8QJudnW013383
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 26 Sep 2006 12:56:40 -0700
Received: from localhost (shell0.pdx.osdl.net [10.9.0.31])
	by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id k8QJucCM031250;
	Tue, 26 Sep 2006 12:56:39 -0700
To: "Zhao, Jing" <Jing.Zhao@chasepaymentech.com>
In-Reply-To: <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>
X-Spam-Status: No, hits=-0.478 required=5 tests=AWL
X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.94__
X-MIMEDefang-Filter: osdl$Revision: 1.152 $
X-Scanned-By: MIMEDefang 2.36
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/27814>



On Tue, 26 Sep 2006, Zhao, Jing wrote:
> 
>  I subscribed git emailing list (git@vger.kernel.org). I don't know for 
> what reason, my post emails all have been rejected. Could you post this 
> for me and shed some light on this issue? thanks,

The vger.kernel.org lists have various spam detectors, and I suspect a 
combination of your email address and the signature you use just triggers 
that system to believe that you are trying to sell us house payment plans 
or something..

So I would suggest removing your signature in particular, that points to a 
web-site that is associated with an industry that has over-used the email 
medium for selling their services...

> I tried to port git to VOS system (Stratus). When i compiled it, i 
> found it did not have 'regex.h' and its library. Do you know any 
> workaround for this problem? Or which package contains these code i can 
> port at first?

I do not know if stratus has regex libraries anywhere, but googling for 
"VOS Stratus regex" seems to be saying that this isn't the first time that 
platform has had problems compiling various programs.

I suspect you'd just have to compile one of the regex libraries that are 
out there as source. I think Henry Spencer's libraries are likely the 
canonical ones, but there's a "GNU regex" too, and that's probably the 
basis for the ones that are used in glibc. Dunno.

Google for either of those, you'll find them. It's not new code, but I 
doubt it needs to be ;)

			Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: your mail
Date: Fri, 20 Oct 2006 16:42:14 +0200 (CEST)
Message-ID: <Pine.LNX.4.63.0610201638510.14200@wbgn013.biozentrum.uni-wuerzburg.de>
References: <E1GavIN-0007Vi-00@dvr.360vision.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: git@vger.kernel.org
X-From: git-owner@vger.kernel.org Fri Oct 20 16:42:58 2006
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by ciao.gmane.org with esmtp (Exim 4.43)
	id 1GavZl-0001wc-Km
	for gcvg-git@gmane.org; Fri, 20 Oct 2006 16:42:22 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1946361AbWJTOmR (ORCPT <rfc822;gcvg-git@m.gmane.org>);
	Fri, 20 Oct 2006 10:42:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946411AbWJTOmR
	(ORCPT <rfc822;git-outgoing>); Fri, 20 Oct 2006 10:42:17 -0400
Received: from mail.gmx.de ([213.165.64.20]:34258 "HELO mail.gmx.net")
	by vger.kernel.org with SMTP id S1946361AbWJTOmR (ORCPT
	<rfc822;git@vger.kernel.org>); Fri, 20 Oct 2006 10:42:17 -0400
Received: (qmail invoked by alias); 20 Oct 2006 14:42:15 -0000
Received: from wbgn013.biozentrum.uni-wuerzburg.de (EHLO dumbo2) [132.187.25.13]
  by mail.gmx.net (mp042) with SMTP; 20 Oct 2006 16:42:15 +0200
X-Authenticated: #1490710
X-X-Sender: gene099@wbgn013.biozentrum.uni-wuerzburg.de
To: andyparkins@gmail.com
In-Reply-To: <E1GavIN-0007Vi-00@dvr.360vision.com>
X-Y-GMX-Trusted: 0
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/29480>

Hi,

your email is horridly mixed here. I get an empty subject here, and the 
complete email header at the beginning of the email:

On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:

> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
> 
> git-send-email doesn't exist; so don't refer to it in the documentation.

But it does! I just removed it, and "make" remade it. I don't even see in 
the Makefile why it should _not_ be made...

Ciao,
Dscho

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff King <peff@peff.net>
Subject: Re: your mail
Date: Sat, 13 Oct 2007 00:07:12 -0400
Message-ID: <20071013040712.GA27227@coredump.intra.peff.net>
References: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: git@vger.kernel.org
To: Michael Witten <mfwitten@MIT.EDU>
X-From: git-owner@vger.kernel.org Sat Oct 13 06:07:35 2007
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by lo.gmane.org with esmtp (Exim 4.50)
	id 1IgYHh-0004JH-3o
	for gcvg-git-2@gmane.org; Sat, 13 Oct 2007 06:07:29 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1750800AbXJMEHQ (ORCPT <rfc822;gcvg-git-2@m.gmane.org>);
	Sat, 13 Oct 2007 00:07:16 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750770AbXJMEHQ
	(ORCPT <rfc822;git-outgoing>); Sat, 13 Oct 2007 00:07:16 -0400
Received: from 66-23-211-5.clients.speedfactory.net ([66.23.211.5]:4418 "EHLO
	peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750758AbXJMEHP (ORCPT <rfc822;git@vger.kernel.org>);
	Sat, 13 Oct 2007 00:07:15 -0400
Received: (qmail 21863 invoked by uid 111); 13 Oct 2007 04:07:13 -0000
Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2)
    by peff.net (qpsmtpd/0.32) with SMTP; Sat, 13 Oct 2007 00:07:13 -0400
Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Sat, 13 Oct 2007 00:07:12 -0400
Content-Disposition: inline
In-Reply-To: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/60720>

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:

> Now that you mention it, I think the best approach would be to:
> 	
> 	(1) cvsexportcommit
> 	(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> 	(3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite 
> that.

No, I mean rebasing instead of merge. As in, you have a history like
this:

    /--C---D  <-- your master
A--B
    \--C'--D' <-- cvsimport merge tip

where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:

A--B--C'--D'--C--D

except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).

> However, this will not preserve more complicated history such as merges
> from another git repository.

Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.

> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P

Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.

HTH,
-Peff

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: your mail
Date: Wed, 5 Dec 2007 19:01:42 +0000 (GMT)
Message-ID: <Pine.LNX.4.64.0712051901290.27959@racer.site>
References: <Pine.LNX.4.64.0712051858270.27959@racer.site>
 <Pine.LNX.4.64.0712051900370.27959@racer.site>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: git@vger.kernel.org, gitster@pobox.com
X-From: git-owner@vger.kernel.org Wed Dec 05 20:02:45 2007
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by lo.gmane.org with esmtp (Exim 4.50)
	id 1IzzVv-0001Uh-86
	for gcvg-git-2@gmane.org; Wed, 05 Dec 2007 20:02:31 +0100
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751884AbXLETCN (ORCPT <rfc822;gcvg-git-2@m.gmane.org>);
	Wed, 5 Dec 2007 14:02:13 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752106AbXLETCL
	(ORCPT <rfc822;git-outgoing>); Wed, 5 Dec 2007 14:02:11 -0500
Received: from mail.gmx.net ([213.165.64.20]:53108 "HELO mail.gmx.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
	id S1751884AbXLETCK (ORCPT <rfc822;git@vger.kernel.org>);
	Wed, 5 Dec 2007 14:02:10 -0500
Received: (qmail invoked by alias); 05 Dec 2007 19:02:08 -0000
Received: from unknown (EHLO [138.251.11.74]) [138.251.11.74]
  by mail.gmx.net (mp056) with SMTP; 05 Dec 2007 20:02:08 +0100
X-Authenticated: #1490710
X-Provags-ID: V01U2FsdGVkX1/dyi5QTx3d6v/fgZdIlNZpsq5W+HExaGkb3SRBFq
	v6Gf5tYtkgQMWZ
X-X-Sender: gene099@racer.site
In-Reply-To: <Pine.LNX.4.64.0712051900370.27959@racer.site>
X-Y-GMX-Trusted: 0
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/67175>

Hi,

On Wed, 5 Dec 2007, Johannes Schindelin wrote:

> [PATCH 1/6] path-list: add functions to work with unsorted lists

Ooops.

Sorry,
Dscho

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: your mail
Date: Wed, 13 Aug 2008 20:46:13 +0530
Message-ID: <20080813151613.GA6448@skywalker>
References: <1218639268-12267-1-git-send-email-aneesh.kumar@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: pasky@suse.cz, git@vger.kernel.org
To: aneesh.kumar@gmail.com
X-From: git-owner@vger.kernel.org Wed Aug 13 17:17:46 2008
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@gmane.org
Received: from vger.kernel.org ([209.132.176.167])
	by lo.gmane.org with esmtp (Exim 4.50)
	id 1KTI6U-0005z3-3B
	for gcvg-git-2@gmane.org; Wed, 13 Aug 2008 17:17:38 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753018AbYHMPQb (ORCPT <rfc822;gcvg-git-2@m.gmane.org>);
	Wed, 13 Aug 2008 11:16:31 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752998AbYHMPQb
	(ORCPT <rfc822;git-outgoing>); Wed, 13 Aug 2008 11:16:31 -0400
Received: from E23SMTP01.au.ibm.com ([202.81.18.162]:49718 "EHLO
	e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752867AbYHMPQa (ORCPT <rfc822;git@vger.kernel.org>);
	Wed, 13 Aug 2008 11:16:30 -0400
Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225])
	by e23smtp01.au.ibm.com (8.13.1/8.13.1) with ESMTP id m7DFGnGr001479
	for <git@vger.kernel.org>; Thu, 14 Aug 2008 01:16:49 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7DFGSfi255904
	for <git@vger.kernel.org>; Thu, 14 Aug 2008 01:16:28 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7DFGRPT026708
	for <git@vger.kernel.org>; Thu, 14 Aug 2008 01:16:28 +1000
Received: from skywalker ([9.77.121.107])
	by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7DFGDeP026560
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Aug 2008 01:16:24 +1000
Content-Disposition: inline
In-Reply-To: <1218639268-12267-1-git-send-email-aneesh.kumar@gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/92229>

On Wed, Aug 13, 2008 at 08:24:28PM +0530, aneesh.kumar@gmail.com wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> topgit: Implement tg-import
> 
> This can be used to import a set of commits
> between range specified by range1..range2
> This should help us to convert an already
> existing quilt, stgit branches to topgit
> managed one
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> ---
>  Makefile     |    2 +-
>  README       |    7 ++++++
>  tg-create.sh |   22 ++++++++----------
>  tg-export.sh |    2 +-
>  tg-import.sh |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 87 insertions(+), 14 deletions(-)
> 

tg-create.sh and tg-export.sh should not be part of this patch. I will
send a new version.

-aneesh

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcus Karlsson <mk@acc.umu.se>
Subject: Re: your mail
Date: Sun, 6 May 2012 19:04:32 +0200
Message-ID: <20120506170432.GA5725@moj>
References: <CAJs0mJfAXgykqexfC1vDcp0f+N6FSLm4jfEjRvqU_ba5FXWP0A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: git@vger.kernel.org
To: Bruce Zu <zu.bruce.china@gmail.com>
X-From: git-owner@vger.kernel.org Sun May 06 19:05:02 2012
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@plane.gmane.org
Received: from vger.kernel.org ([209.132.180.67])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <git-owner@vger.kernel.org>)
	id 1SR4tH-0006rt-Jr
	for gcvg-git-2@plane.gmane.org; Sun, 06 May 2012 19:04:59 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754086Ab2EFREy (ORCPT <rfc822;gcvg-git-2@m.gmane.org>);
	Sun, 6 May 2012 13:04:54 -0400
Received: from mail.acc.umu.se ([130.239.18.156]:36294 "EHLO mail.acc.umu.se"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754056Ab2EFREx (ORCPT <rfc822;git@vger.kernel.org>);
	Sun, 6 May 2012 13:04:53 -0400
Received: from localhost (localhost [127.0.0.1])
	by amavisd-new (Postfix) with ESMTP id 7E8F3DB4;
	Sun,  6 May 2012 19:04:52 +0200 (MEST)
X-Virus-Scanned: amavisd-new at acc.umu.se
Received: from moj (c-0971e155.122-2-64736c10.cust.bredbandsbolaget.se [85.225.113.9])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: mk)
	by mail.acc.umu.se (Postfix) with ESMTPSA id 5676CDB3;
	Sun,  6 May 2012 19:04:51 +0200 (MEST)
Content-Disposition: inline
In-Reply-To: <CAJs0mJfAXgykqexfC1vDcp0f+N6FSLm4jfEjRvqU_ba5FXWP0A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/197203>

On Sun, May 06, 2012 at 10:17:07PM +0800, Bruce Zu wrote:
> I want subscribe this git mail list
> thanks!
> Bruce Zu

Great idea. The instructions for how to subscribe can be found on
http://vger.kernel.org/. Then subscribe to the list named 'git'.

	Marcus

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Magnus =?iso-8859-1?Q?B=E4ck?= <baeck@google.com>
Subject: Re: your mail
Date: Tue, 21 May 2013 09:13:35 -0400
Message-ID: <20130521131334.GB634@google.com>
References: <CAED3JAZa8iB=rZqZ9sUfAqqtzHaMS3-6m0r=TnaBBRtYTF0XMw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: git@vger.kernel.org
To: ASHISH VERMA <ashunew1989@gmail.com>
X-From: git-owner@vger.kernel.org Tue May 21 15:13:42 2013
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@plane.gmane.org
Received: from vger.kernel.org ([209.132.180.67])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <git-owner@vger.kernel.org>)
	id 1UemNp-0002Kw-Ts
	for gcvg-git-2@plane.gmane.org; Tue, 21 May 2013 15:13:42 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754512Ab3EUNNh convert rfc822-to-quoted-printable (ORCPT
	<rfc822;gcvg-git-2@m.gmane.org>); Tue, 21 May 2013 09:13:37 -0400
Received: from mail-qc0-f202.google.com ([209.85.216.202]:50816 "EHLO
	mail-qc0-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754472Ab3EUNNg (ORCPT <rfc822;git@vger.kernel.org>);
	Tue, 21 May 2013 09:13:36 -0400
Received: by mail-qc0-f202.google.com with SMTP id d1so50811qcz.5
        for <git@vger.kernel.org>; Tue, 21 May 2013 06:13:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:content-transfer-encoding
         :in-reply-to:user-agent;
        bh=L3T2xsM+vj2Ivrsf8R9LkBI0M6lk2QCMc+yDaA9M9N8=;
        b=NLSqZ5d3GjGaUSxUTE68wfe7Qx2HKeeLJTjb7eaL98+4OUsQ7AwCG/v4EEadVkQwf8
         jEzy1lP9VQmczuGDYvnoZqAAqf+RKQpa6t40kLAy3yNpm483DjJIvREB+2TM7kS2G27l
         /8F4tTKxRhmdnCxgwnfkLVPULLoCi3bKRJG/MrzUYDdW6sAr6BDIs5O8RPBnwJhbwTP3
         /9bvE/wwbvUHSt6Nlog/xeFuEdP3AiNs3GaZYUVHibCjaoPyleVx9sqV3Y0TGFdrTN2j
         87nD13dqYMesH0Arixwy2c/ggWatwmQpORlZm+sBT5HHTS3k2f0qJS3ydD3IlNdzb+8Y
         7vHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:content-transfer-encoding
         :in-reply-to:user-agent:x-gm-message-state;
        bh=L3T2xsM+vj2Ivrsf8R9LkBI0M6lk2QCMc+yDaA9M9N8=;
        b=RZGDUbvCz8TnU2l5eCMMLGJBAfKJVStcdc7RJtl39aCYPlNl70Ee9gE5QbwVvl8wQ3
         l8SNsFTt8P+Dwr68Whh4UMoOAV28czOcM+RNptO2fYkhCyWgiWp5qdikIdv93efoWXq7
         0bFLBaL74K2TQ94GtdYWNKUvNUvY983Tmn6i0+Z1De7Ebl4rW1YTGNraLJnSDerEHrun
         FRaTUhXIZ8FzwbAaalRQjmUtKxJYxBXyQAdsrH722DtWcqx+LUC+EJHCUbr8MjIDgFkR
         ZCryIB7Jkv8aCUViZR1zH2vF3F1s3Q3sD/rrqIb6+0qbo1JCy/NJnYOG5LBvHupERuPc
         cN/A==
X-Received: by 10.236.141.37 with SMTP id f25mr1166944yhj.50.1369142015987;
        Tue, 21 May 2013 06:13:35 -0700 (PDT)
Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93])
        by gmr-mx.google.com with ESMTPS id u47si234814yhe.0.2013.05.21.06.13.35
        for <multiple recipients>
        (version=TLSv1.1 cipher=AES128-SHA bits=128/128);
        Tue, 21 May 2013 06:13:35 -0700 (PDT)
Received: from valle.nyc.corp.google.com (valle.nyc.corp.google.com [172.26.78.170])
	by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id DBD0A5A42D2;
	Tue, 21 May 2013 06:13:35 -0700 (PDT)
Received: by valle.nyc.corp.google.com (Postfix, from userid 159662)
	id 76E1040783; Tue, 21 May 2013 09:13:35 -0400 (EDT)
Content-Disposition: inline
In-Reply-To: <CAED3JAZa8iB=rZqZ9sUfAqqtzHaMS3-6m0r=TnaBBRtYTF0XMw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkMem5tSRbtCy6NGhP6mbMULaOC5WFJuolmVh3Oz68J9GTonKz2HB7Txvlc4Wd9LgQbeCPCeLkoo/l/ea6mwLd7BlSnbsHAUR+i6tCZyYK3n7mJONCEDYL8KMlEUpxI75iSahQCGqQD4YBj86e4GTkaiTstj21cabo6dz7XfKIiEc8JU2K3BX2DMONQzvKno+A8U+Zc
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/225029>

On Friday, May 17, 2013 at 14:02 EDT,
     ASHISH VERMA <ashunew1989@gmail.com> wrote:

> Hi,  i am using git to push my code from eclipse to heroku , but
> recently iam  getting error like::
>=20
> master:master rejected:non fast forward
>=20
> and i am not able to resolve it .I tried a git pull but that says -
> conflicts shud be resolved before git pull can be implemented.I can;t
> find the solution Please help ASAP...

Resolve the conflicts by either hand-editing the files (you'll see the
markers where the conflicts are) add running 'git add' to tell git that
you're done resolving them, or set up Git to use a graphical tool like
kdiff3. When you're done, run 'git commit' to create the merge commit.
After that you'll be able to push to your upstream (unless things have
moved again while you were resolving the initial conflict).

This guide to merge conflicts looks pretty good:
http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/

--=20
Magnus B=E4ck
baeck@google.com

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff King <peff@peff.net>
Subject: Re: your mail
Date: Mon, 11 Apr 2016 15:13:12 -0400
Message-ID: <20160411191311.GA9057@sigill.intra.peff.net>
References: <001a11492f107354a305303a369a@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: git@vger.kernel.org
To: miwilliams@google.com
X-From: git-owner@vger.kernel.org Mon Apr 11 21:13:21 2016
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git-2@plane.gmane.org
Received: from vger.kernel.org ([209.132.180.67])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <git-owner@vger.kernel.org>)
	id 1aphGy-0006Pr-99
	for gcvg-git-2@plane.gmane.org; Mon, 11 Apr 2016 21:13:20 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754888AbcDKTNQ (ORCPT <rfc822;gcvg-git-2@m.gmane.org>);
	Mon, 11 Apr 2016 15:13:16 -0400
Received: from cloud.peff.net ([50.56.180.127]:47651 "HELO cloud.peff.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
	id S1754403AbcDKTNP (ORCPT <rfc822;git@vger.kernel.org>);
	Mon, 11 Apr 2016 15:13:15 -0400
Received: (qmail 13534 invoked by uid 102); 11 Apr 2016 19:13:14 -0000
Received: from Unknown (HELO peff.net) (10.0.1.2)
    by cloud.peff.net (qpsmtpd/0.84) with SMTP; Mon, 11 Apr 2016 15:13:14 -0400
Received: (qmail 28833 invoked by uid 107); 11 Apr 2016 19:13:19 -0000
Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7)
    by peff.net (qpsmtpd/0.84) with SMTP; Mon, 11 Apr 2016 15:13:19 -0400
Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 11 Apr 2016 15:13:12 -0400
Content-Disposition: inline
In-Reply-To: <001a11492f107354a305303a369a@google.com>
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/291227>

On Mon, Apr 11, 2016 at 07:04:23PM +0000, miwilliams@google.com wrote:

> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb

These bits (minus the initial "From ..." line) should go into your
actual email headers. As it is, your email has no subject line.

> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!) when determining whether or not a submodule has new
> commits.
> [...]
> -			d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
> +			d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);

It's not extraneous. hashcmp() returns 0 for equality, but an arbitrary
positive or negative value depending on how the two arguments differ.
The assigned "new_submodule_commits" is a bitfield of size 1. So the
"!!" is normalizing the value into "0" or "1".

-Peff

From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.176.0/21
X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
From: Davide Libenzi <davidel@xmailserver.org>
Subject: Re: your mail
Date: Wed, 22 Nov 2006 12:16:58 -0800 (PST)
Message-ID: <Pine.LNX.4.64.0611221208430.27569@alien.or.mcafeemobile.com>
References: <Pine.LNX.4.63.0611212316080.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
NNTP-Posting-Date: Wed, 22 Nov 2006 20:17:40 +0000 (UTC)
Cc: git@vger.kernel.org
Return-path: <git-owner@vger.kernel.org>
Envelope-to: gcvg-git@gmane.org
X-AuthUser: davidel@xmailserver.org
X-X-Sender: davide@alien.or.mcafeemobile.com
In-Reply-To: <Pine.LNX.4.63.0611212316080.26827@wbgn013.biozentrum.uni-wuerzburg.de>
X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640  56FE 0974 BF23 270F 474E
X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/32098>
Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with
 esmtp (Exim 4.43) id 1GmyX3-0000yi-HM for gcvg-git@gmane.org; Wed, 22 Nov
 2006 21:17:22 +0100
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id
 S1756990AbWKVURR (ORCPT <rfc822;gcvg-git@m.gmane.org>); Wed, 22 Nov 2006
 15:17:17 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756992AbWKVURR
 (ORCPT <rfc822;git-outgoing>); Wed, 22 Nov 2006 15:17:17 -0500
Received: from x35.xmailserver.org ([69.30.125.51]:28115 "EHLO
 x35.xmailserver.org") by vger.kernel.org with ESMTP id S1756989AbWKVURQ
 (ORCPT <rfc822;git@vger.kernel.org>); Wed, 22 Nov 2006 15:17:16 -0500
Received: from alien.or.mcafeemobile.com by x35.xmailserver.org with [XMail
 1.23 ESMTP Server] id <S200309> for <git@vger.kernel.org> from
 <davidel@xmailserver.org>; Wed, 22 Nov 2006 12:16:59 -0800
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Sender: git-owner@vger.kernel.org

On Tue, 21 Nov 2006, Johannes Schindelin wrote:

> [PATCH] xdiff: add xdl_merge()
> 
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
> 
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
> 
> - a level value of 0 means that all overlapping changes are treated
>   as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
>   it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
>   almost identical changes will not result in huge conflicts. Rather,
>   only the conflicting lines will be shown inside conflict markers.
> 
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.

Johannes, at the moment I'm chased by a huge storm of never ending emails, 
so I won't be able to follow up this one soon. A smart 3-way merge is in 
my plans for LibXDiff though.
There is quite some nice code around, that does pretty smart tricks and 
goes down to resolve sub-hunk non-trivial conflicts. You may want to take 
a look at that code too.



- Davide


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 24C2D1FA7B
	for <e@80x24.org>; Thu, 22 Jun 2017 12:50:27 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752826AbdFVMuZ (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 08:50:25 -0400
Received: from zucker.schokokeks.org ([178.63.68.96]:35933 "EHLO
        zucker.schokokeks.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751835AbdFVMuY (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 08:50:24 -0400
Received: from localhost ([::1])
  (AUTH: PLAIN simon@ruderich.org, TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384)
  by zucker.schokokeks.org with ESMTPSA; Thu, 22 Jun 2017 14:48:03 +0200
  id 0000000000000274.00000000594BBC83.000008A1
Date:   Thu, 22 Jun 2017 14:48:03 +0200
From:   Simon Ruderich <simon@ruderich.org>
To:     Jessie Hernandez <git@jessiehernandez.com>
Cc:     git@vger.kernel.org
Subject: Re: your mail
Message-ID: <20170622124803.45sduodpfbwuuq52@ruderich.org>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
User-Agent: NeoMutt/20170306 (1.8.0)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git

You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id B7E201FA7B
	for <e@80x24.org>; Thu, 22 Jun 2017 13:47:12 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751806AbdFVNrK (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 09:47:10 -0400
Received: from zucker.schokokeks.org ([178.63.68.96]:35723 "EHLO
        zucker.schokokeks.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750847AbdFVNrK (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 09:47:10 -0400
Received: from localhost ([::1])
  (AUTH: PLAIN simon@ruderich.org, TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384)
  by zucker.schokokeks.org with ESMTPSA; Thu, 22 Jun 2017 15:47:08 +0200
  id 000000000000002C.00000000594BCA5C.00000A50
Date:   Thu, 22 Jun 2017 15:47:08 +0200
From:   Simon Ruderich <simon@ruderich.org>
To:     Patrick Lehmann <Patrick.Lehmann@plc2.de>
Cc:     Jessie Hernandez <git@jessiehernandez.com>, git@vger.kernel.org
Subject: Re: your mail
Message-ID: <20170622134708.fcc4zxakga6p255x@ruderich.org>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
 <20170622124803.45sduodpfbwuuq52@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
User-Agent: NeoMutt/20170306 (1.8.0)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?

Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.

Regards
Simon
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 6D67F20802
	for <e@80x24.org>; Thu, 22 Jun 2017 20:46:49 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753400AbdFVUqd (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 16:46:33 -0400
Received: from zucker.schokokeks.org ([178.63.68.96]:49445 "EHLO
        zucker.schokokeks.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752695AbdFVUqb (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 16:46:31 -0400
Received: from localhost ([::1])
  (AUTH: PLAIN simon@ruderich.org, TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384)
  by zucker.schokokeks.org with ESMTPSA; Thu, 22 Jun 2017 22:46:30 +0200
  id 000000000000007E.00000000594C2CA6.00000926
Date:   Thu, 22 Jun 2017 22:46:29 +0200
From:   Simon Ruderich <simon@ruderich.org>
To:     Patrick Lehmann <Patrick.Lehmann@plc2.de>
Cc:     Jessie Hernandez <git@jessiehernandez.com>,
        "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20170622204628.eintlap4uchlncub@ruderich.org>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
 <20170622124803.45sduodpfbwuuq52@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
 <20170622134708.fcc4zxakga6p255x@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
User-Agent: NeoMutt/20170306 (1.8.0)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
> The description on https://github.com/git/git doesn't reflect that policy.
>
> a)
> It explains that discussions take place in the mentioned mailing list.
> b)
> It describes how to subscribe.

However it doesn't say that you have to subscribe to send, only
how to subscribe.

> With knowledge of other mailing lists (mostly managed by mailman),
> subscription is required for participation.

That depends on the mailing list, some require subscription to
prevent spams but not all do.

Somebody might want to update the documentation, but personally
I see no reason to change anything. If you want to send a patch
to improve it, that would be great of course.

Regards
Simon

PS: Please don't top-post on this mailing list.
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_DKIM_INVALID,
	T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 161FB20802
	for <e@80x24.org>; Thu, 22 Jun 2017 21:35:40 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753512AbdFVVfi (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 17:35:38 -0400
Received: from mail-pg0-f52.google.com ([74.125.83.52]:36446 "EHLO
        mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752424AbdFVVfh (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 17:35:37 -0400
Received: by mail-pg0-f52.google.com with SMTP id u62so12987548pgb.3
        for <git@vger.kernel.org>; Thu, 22 Jun 2017 14:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version;
        bh=9wywWJ0Oon3JGGYY6TjEPEBwUDrnlyUtn0/NvpdCWhs=;
        b=YDm47wxiLdyinSZoYLNsT30AGymAUN1dQlWg1q24srSuxUuykzP026ABX8JOouE/5l
         bpHmXu+oNUnrYNnKf11o2Tu+qO/Br4xVI256yzno+6TbSm5NLMaq5xqvghpzETI/uIBd
         Iiy77TENQc1lMT2TSGfXBR2jR5h9mqOeL/+u4jU4w1vSdTaMbhNwYTbJsMR9zoMJKEYC
         p7W2gBhDjnf9dl9UWtu4vGyfgVkhcUduAW0osYJwFt69ao933WQIjGA4XZBSKU0wxr97
         D9QCLQaaASyr+fe7fu5ioQuIpHO24Zb+IpF+i90BLXW60RddmQvhUygFMN3CSKSjIPQ4
         sxaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:sender:from:to:cc:subject:references:date
         :in-reply-to:message-id:user-agent:mime-version;
        bh=9wywWJ0Oon3JGGYY6TjEPEBwUDrnlyUtn0/NvpdCWhs=;
        b=D0kxxOBLa8yuWAEow18mm5zL82v+MSZ6EgcfXAx8n/bPvIT97jJO+iHTTSnH/TW/LL
         QACsDmkY+N1cOJLtidv1k1gsPvy/PW8wo0H7QzMzfVGYBderYPQv0GCiyBLX19042/si
         InMLYTp2LVfeJQ00nl7PeXasY03EwkyT0A7vEJWsNlGvoE9dtjHMlaWMeTxDpCxNIgVp
         oB2ILTmlLpUNWXTflxCQQfYniz99PIyrIVwPnPznZmV0jMFo4NxJYqHo034K1GUUiB3e
         inRDsPJiCBRx5rRWIq5HZQEVo8XSKoNDm3naFnGfByLU5e8haj7kJ128Hd8/nShf/tvC
         9m8w==
X-Gm-Message-State: AKS2vOwd6i8i7VnCrhzbTN/OlsBWODclQVVqvKeVP7PN3iUc0mn4l4Uc
        w7suNm4drbP4Wg==
X-Received: by 10.99.127.76 with SMTP id p12mr4741994pgn.258.1498167336357;
        Thu, 22 Jun 2017 14:35:36 -0700 (PDT)
Received: from localhost ([2620:0:1000:8622:20f6:6e44:6707:50bd])
        by smtp.gmail.com with ESMTPSA id l63sm5849529pfc.132.2017.06.22.14.35.35
        (version=TLS1_2 cipher=AES128-SHA bits=128/128);
        Thu, 22 Jun 2017 14:35:35 -0700 (PDT)
From:   Junio C Hamano <gitster@pobox.com>
To:     Simon Ruderich <simon@ruderich.org>
Cc:     Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
        <20170622124803.45sduodpfbwuuq52@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
        <20170622134708.fcc4zxakga6p255x@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
        <20170622204628.eintlap4uchlncub@ruderich.org>
Date:   Thu, 22 Jun 2017 14:35:34 -0700
In-Reply-To: <20170622204628.eintlap4uchlncub@ruderich.org> (Simon Ruderich's
        message of "Thu, 22 Jun 2017 22:46:29 +0200")
Message-ID: <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Simon Ruderich <simon@ruderich.org> writes:

> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>> The description on https://github.com/git/git doesn't reflect that policy.
>>
>> a)
>> It explains that discussions take place in the mentioned mailing list.
>> b)
>> It describes how to subscribe.
>
> However it doesn't say that you have to subscribe to send, only
> how to subscribe.

For that matter, we also say "everyone is welcome to post", which
makes it clear that no subscription is required.

But I view these merely being technically correct.  And making it
absolutely obvious does not cost too much.

>> With knowledge of other mailing lists (mostly managed by mailman),
>> subscription is required for participation.
>
> That depends on the mailing list, some require subscription to
> prevent spams but not all do.

Yes.  But not many people realize that the world they know is the
only world.  We are used to an open list and are shocked when we
encouter a closed one; let's not forget that shock.

How about doing it like this?

 README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README.md b/README.md
index f17af66a97..bbaf54bffb 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
 mailing list -- everyone is welcome to post bug reports, feature
 requests, comments and patches to git@vger.kernel.org (read
 [Documentation/SubmittingPatches][] for instructions on patch submission).
+
+You can send messages without subscribing to the list, but it is 
+recommended to read what other people are saying on the list before
+you speak.
 To subscribe to the list, send an email with just "subscribe git" in
 the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.3 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id A0D8020802
	for <e@80x24.org>; Thu, 22 Jun 2017 21:58:16 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753261AbdFVV6N (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 17:58:13 -0400
Received: from mail-wr0-f194.google.com ([209.85.128.194]:34462 "EHLO
        mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752071AbdFVV6M (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 17:58:12 -0400
Received: by mail-wr0-f194.google.com with SMTP id k67so7869262wrc.1
        for <git@vger.kernel.org>; Thu, 22 Jun 2017 14:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=from:to:cc:subject:references:user-agent:in-reply-to:date
         :message-id:mime-version;
        bh=fZDQvRVqWL/OBF+K1RNsoTu7dedecf6AGwN/9PP71w0=;
        b=jOalMhRORoWTRRGq5Wr7F3jSbiXBcEv9PvTuS/RcPdApGLQDlcoyFzOMW4/hCcyvk5
         Z5UmyJBi4mLVPVFywZg5Kxi4Tol4Ska+roor3jbg02kZOjTMmzNOMQRjs++w3ZVQMtQc
         Ret9oDtJXbm5WVe560sFwPEWWoSjO50ADDHwV1rz54wKeRUjGbgr5tX8sgtw3frfLSY9
         IUmRCBB7XlO1KEhsF9KT54oJKj7ew9w5Py5cPAPS0GXMLF14Bqvg04wajp7dW1kJKGSj
         274nbBwGdEnMACK1lAzaujzxr3N/tjFSzWE0HQK+Ba7pQ4gFIQn9l23SATiwpULyNIS/
         6fmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:from:to:cc:subject:references:user-agent
         :in-reply-to:date:message-id:mime-version;
        bh=fZDQvRVqWL/OBF+K1RNsoTu7dedecf6AGwN/9PP71w0=;
        b=YTuVZ0/9b+jrX5z96qfDKrjgrNxVRDX2rCH0qazZQ8g5SF2D+KJ+mMmrhZuDTGlX8y
         5Y9E5dqeSgszhnu+ul31unTZTmqUoWcVVGRSDc79hYFcAGKysEO2pHoqDhpqn4qMJY0F
         BvISrtTbyumsWTp0ITr/he+DfPUpV+xQLbk40Gl3ezfmOpOYFvOjXrg2f5+CFAr3KEyj
         6Zjbdxbz8n4/P+r98f5sysDDAXY6uNWt9NtZEJ8pYzEo8uIBoXy5nPpJRS2hA62mP5gm
         tRnyxX0C2TpFdTanjf2wmpf7kbuUORZBpLnAisWtOM7pSPm1m9IvY/jQSWQFpsL8BT8S
         HSdw==
X-Gm-Message-State: AKS2vOxvRmXJz1c693aLe8+EEbGuKXqqsoN4sohmEewPvLrHOvbqlITV
        a3Cm4y8Zz627SNGt/2M=
X-Received: by 10.80.145.25 with SMTP id e25mr3990325eda.8.1498168691274;
        Thu, 22 Jun 2017 14:58:11 -0700 (PDT)
Received: from snth (g74110.upc-g.chello.nl. [80.57.74.110])
        by smtp.gmail.com with ESMTPSA id e28sm227062ede.14.2017.06.22.14.58.09
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 22 Jun 2017 14:58:09 -0700 (PDT)
Received: from avar by snth with local (Exim 4.84_2)
        (envelope-from <avarab@gmail.com>)
        id 1dOA76-0005HQ-Ul; Thu, 22 Jun 2017 23:58:08 +0200
From:   =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>
To:     Junio C Hamano <gitster@pobox.com>
Cc:     Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com> <20170622124803.45sduodpfbwuuq52@ruderich.org> <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de> <20170622134708.fcc4zxakga6p255x@ruderich.org> <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de> <20170622204628.eintlap4uchlncub@ruderich.org> <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
User-agent: Debian GNU/Linux 8.8 (jessie); Emacs 25.1.1; mu4e 0.9.19
In-reply-to: <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
Date:   Thu, 22 Jun 2017 23:58:08 +0200
Message-ID: <878tkjk7m7.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org


On Thu, Jun 22 2017, Junio C. Hamano jotted:

> Simon Ruderich <simon@ruderich.org> writes:
>
>> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>>> The description on https://github.com/git/git doesn't reflect that policy.
>>>
>>> a)
>>> It explains that discussions take place in the mentioned mailing list.
>>> b)
>>> It describes how to subscribe.
>>
>> However it doesn't say that you have to subscribe to send, only
>> how to subscribe.
>
> For that matter, we also say "everyone is welcome to post", which
> makes it clear that no subscription is required.
>
> But I view these merely being technically correct.  And making it
> absolutely obvious does not cost too much.
>
>>> With knowledge of other mailing lists (mostly managed by mailman),
>>> subscription is required for participation.
>>
>> That depends on the mailing list, some require subscription to
>> prevent spams but not all do.
>
> Yes.  But not many people realize that the world they know is the
> only world.  We are used to an open list and are shocked when we
> encouter a closed one; let's not forget that shock.
>
> How about doing it like this?
>
>  README.md | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/README.md b/README.md
> index f17af66a97..bbaf54bffb 100644
> --- a/README.md
> +++ b/README.md
> @@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
>  mailing list -- everyone is welcome to post bug reports, feature
>  requests, comments and patches to git@vger.kernel.org (read
>  [Documentation/SubmittingPatches][] for instructions on patch submission).
> +
> +You can send messages without subscribing to the list, but it is
> +recommended to read what other people are saying on the list before
> +you speak.
>  To subscribe to the list, send an email with just "subscribe git" in
>  the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,

It's unclear what that means. I *think* it means "consider taking a look
around the list before you post", but then it's probably better advice
to tell people to skim the archives first to get an idea of the traffic.

E.g. if I page through the first 2 pages of public-inbox.org I get
messages going back to the 19th, but if I were to subscribe to the list
I'd need to wait 4 days to get the same mail.

Which, in the context of what this follows (how to submit a bug,
questions etc.) isn't a good use of time for the person reading the
instructions.

Maybe something more like:

diff --git a/README.md b/README.md
index f17af66a97..dc175757fa 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,
 <http://marc.info/?l=git> and other archival sites.

+You don't need to be subscribed to the list to send mail to it, and
+others on-list will generally CC you when replying (although some
+forget this). It's adviced to subscribe to the list if you want to be
+sure you're not missing follow-up discussion, or if your interest in
+the project is wider than a one-off bug report, question or patch.
+
 The maintainer frequently sends the "What's cooking" reports that
 list the current status of various development topics to the mailing
 list.  The discussion following them give a good reference for

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_DKIM_INVALID,
	T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id A638C20802
	for <e@80x24.org>; Thu, 22 Jun 2017 22:15:02 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753482AbdFVWPB (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 18:15:01 -0400
Received: from mail-pg0-f67.google.com ([74.125.83.67]:33237 "EHLO
        mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752071AbdFVWPA (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 18:15:00 -0400
Received: by mail-pg0-f67.google.com with SMTP id u62so4021291pgb.0
        for <git@vger.kernel.org>; Thu, 22 Jun 2017 15:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-transfer-encoding;
        bh=H0yaPMccxgUdl5Ud+pNrcmexEytufiWMX4Ca8wIB39s=;
        b=dYWzzLOPji9LYw6lmqajr6mG+EaOauYXfNwVIYxQD7M8Zc0+dJnyk79sglEW5JBaSx
         WQ3PhQlpBCVw34JOKU8r65xUWa7uZzBphfE86tYwX2UlAy1YhVBK72pPmDrbZ1UGzNLh
         HGIV2Y6NP4UAT9tZnRq/qKIbpXnu8FhDQB3aUvmkCjkU4ym90B5nlo58HofT7cWWEYGC
         YlD4MOETUq9oxCxBjbM81u+Grnmg36RSaz8KearqQq0cBASU2rqYBKQ+63D7DLMTKtI6
         U+YTBV8cn45gWn1FvECrmdep11XE2qrMgc9/oxbDyU8ONh+iD2ynTIWpB8EMby+giCf8
         CanQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:sender:from:to:cc:subject:references:date
         :in-reply-to:message-id:user-agent:mime-version
         :content-transfer-encoding;
        bh=H0yaPMccxgUdl5Ud+pNrcmexEytufiWMX4Ca8wIB39s=;
        b=f76qfIbqA7yj1fEa6MNRe4QqFw+daLoBLjywSELXbJSE7h/1p+nz77bnITc8OEbsjI
         tYdM6F4LfLLDpr2zAIxE40/U8F5d0C061BCLa10QNKp6wy0o4euTdBienF8pGODvO6y8
         UHg5cPQEfoj0k8qR9s3Z7wWWy/b/3i4pig1Sex42VgIpo1+e9wiBISWd1apgLrTATN+s
         olNgyh3TKDTWhTiy6EjM/Bh+NkMSvc+n6W9xV8TBhAKh+X/ihpz+APW6pgiF/I8ZTMgR
         XOVTjSCvKlx8Yi+gWMoqz67Fn63N6rt5FULc0PMdCT7on4yPNVKSsASOnKCo9g0imiss
         FHkA==
X-Gm-Message-State: AKS2vOzsENmFJFMjeLvEUdMWP3D4YgUvLuDh2F9o30dSnxfwubIzMZLH
        MVzVSXLrSGIyzA==
X-Received: by 10.99.122.13 with SMTP id v13mr4930844pgc.156.1498169698759;
        Thu, 22 Jun 2017 15:14:58 -0700 (PDT)
Received: from localhost ([2620:0:1000:8622:20f6:6e44:6707:50bd])
        by smtp.gmail.com with ESMTPSA id p21sm5896785pgn.12.2017.06.22.15.14.58
        (version=TLS1_2 cipher=AES128-SHA bits=128/128);
        Thu, 22 Jun 2017 15:14:58 -0700 (PDT)
From:   Junio C Hamano <gitster@pobox.com>
To:     =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>
Cc:     Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
        <20170622124803.45sduodpfbwuuq52@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
        <20170622134708.fcc4zxakga6p255x@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
        <20170622204628.eintlap4uchlncub@ruderich.org>
        <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
        <878tkjk7m7.fsf@gmail.com>
Date:   Thu, 22 Jun 2017 15:14:57 -0700
In-Reply-To: <878tkjk7m7.fsf@gmail.com> (=?utf-8?B?IsOGdmFyIEFybmZqw7Zy?=
 =?utf-8?B?w7A=?= Bjarmason"'s message
        of "Thu, 22 Jun 2017 23:58:08 +0200")
Message-ID: <xmqqr2ybhdpa.fsf@gitster.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Ăvar ArnfjĂśrĂ° Bjarmason <avarab@gmail.com> writes:

> Maybe something more like:

Much better.

> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 4FF4020802
	for <e@80x24.org>; Thu, 22 Jun 2017 23:22:06 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753957AbdFVXV7 (ORCPT <rfc822;e@80x24.org>);
        Thu, 22 Jun 2017 19:21:59 -0400
Received: from cloud.peff.net ([104.130.231.41]:49638 "HELO cloud.peff.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
        id S1753649AbdFVXV6 (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 22 Jun 2017 19:21:58 -0400
Received: (qmail 31308 invoked by uid 109); 22 Jun 2017 23:21:58 -0000
Received: from Unknown (HELO peff.net) (10.0.1.2)
 by cloud.peff.net (qpsmtpd/0.94) with SMTP; Thu, 22 Jun 2017 23:21:58 +0000
Authentication-Results: cloud.peff.net; auth=none
Received: (qmail 7128 invoked by uid 111); 22 Jun 2017 23:22:02 -0000
Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7)
    by peff.net (qpsmtpd/0.84) with SMTP; Thu, 22 Jun 2017 19:22:02 -0400
Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Thu, 22 Jun 2017 19:21:56 -0400
Date:   Thu, 22 Jun 2017 19:21:56 -0400
From:   Jeff King <peff@peff.net>
To:     =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>
Cc:     Junio C Hamano <gitster@pobox.com>,
        Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20170622232156.vptuoafdtglokujw@sigill.intra.peff.net>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
 <20170622124803.45sduodpfbwuuq52@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
 <20170622134708.fcc4zxakga6p255x@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
 <20170622204628.eintlap4uchlncub@ruderich.org>
 <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
 <878tkjk7m7.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <878tkjk7m7.fsf@gmail.com>
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jun 22, 2017 at 11:58:08PM +0200, Ăvar ArnfjĂśrĂ° Bjarmason wrote:

> Which, in the context of what this follows (how to submit a bug,
> questions etc.) isn't a good use of time for the person reading the
> instructions.
> 
> Maybe something more like:
> 
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
> 
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

You perhaps already read it, but you may want to steal wording or
suggestions from the mailing list section at:

  https://git-scm.com/community

which is covering the same ideas (and vice versa, patches to that page
are welcome if the README says something better).

-Peff

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_DKIM_INVALID,
	T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 3B5DE2082E
	for <e@80x24.org>; Fri, 23 Jun 2017 05:23:24 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754007AbdFWFXV (ORCPT <rfc822;e@80x24.org>);
        Fri, 23 Jun 2017 01:23:21 -0400
Received: from mail-pf0-f171.google.com ([209.85.192.171]:33164 "EHLO
        mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753269AbdFWFXU (ORCPT <rfc822;git@vger.kernel.org>);
        Fri, 23 Jun 2017 01:23:20 -0400
Received: by mail-pf0-f171.google.com with SMTP id e7so18974716pfk.0
        for <git@vger.kernel.org>; Thu, 22 Jun 2017 22:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-transfer-encoding;
        bh=eBaeJXpfUeb5Q8hae+gSOxm1kuLc12aNEr+ctJ9jCmM=;
        b=gO1Ws5l4od5OWGN2zacSCG6bgASk8Dy8fG78pJyfdLxiVY1E/I/2ebGJqZhtPRop4c
         fqSdsodckQze1C3n535eQIlxZRTCKM7as/fLowUUZV49OLj2bECDNJ3PcByLWn87585K
         rYcr4EMWecN9bmnu9E9DjTnRf2GkGPsmXgN2m5rB5Mk15gqepk4fGe0+L5FrixxRgjLJ
         b0IjYgTEyozAD9ZK0kk1G/JzFVYLSTgLqoW34kiamtRfc7pGdLJyCI3AxIrHJJD+MrLN
         9g/zI4kUyeKxhyme2JXuirp9BxEb1EolBH8E/gpqiZSTeaq4M5Z9wm4vAPRIa/wQZBxH
         d4lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:sender:from:to:cc:subject:references:date
         :in-reply-to:message-id:user-agent:mime-version
         :content-transfer-encoding;
        bh=eBaeJXpfUeb5Q8hae+gSOxm1kuLc12aNEr+ctJ9jCmM=;
        b=IIrgZqBUYG5WzkxFDFk0BuwksRSyYSW7VPTuuFA01Jp1nvwqRj+bVM2Iz2RW8s0bE5
         NH2mimtEt1GdQypbDjKgKUFvgg+OjaN1GC7LkUDN7+GPZzjeJICqnTUXZYFx4/SrwMn7
         UxDL5W0uwUyaTBzGyf713MFeARNdWy58aq0e1HWAVQEhgzy3AwsyiGD+AJJbmwnoYlQU
         bZasEZe29nP+TQnA1d2GohCsLwKlRpSvheHEaeaPxu1E3llAo+tb7kzs3zmXwaxYH7Ec
         YSxkDP/98iWRrXFl/n0yYKR6mot8KI7w1UDYS8D+8RdtIHjahxPzIJOWwJmwm1rhrDRd
         bu8w==
X-Gm-Message-State: AKS2vOwybpasYlF2VADa12a59qeOdZ+OBE6cIrShAuLGYcoyDJ/TDxtN
        3opMaLVD+JRejw==
X-Received: by 10.98.58.78 with SMTP id h75mr6203698pfa.50.1498195399647;
        Thu, 22 Jun 2017 22:23:19 -0700 (PDT)
Received: from localhost ([2620:0:1000:8622:20f6:6e44:6707:50bd])
        by smtp.gmail.com with ESMTPSA id u73sm7279210pfi.105.2017.06.22.22.23.18
        (version=TLS1_2 cipher=AES128-SHA bits=128/128);
        Thu, 22 Jun 2017 22:23:18 -0700 (PDT)
From:   Junio C Hamano <gitster@pobox.com>
To:     Jeff King <peff@peff.net>
Cc:     =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>,
        Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
        <20170622124803.45sduodpfbwuuq52@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
        <20170622134708.fcc4zxakga6p255x@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
        <20170622204628.eintlap4uchlncub@ruderich.org>
        <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
        <878tkjk7m7.fsf@gmail.com>
        <20170622232156.vptuoafdtglokujw@sigill.intra.peff.net>
Date:   Thu, 22 Jun 2017 22:23:17 -0700
In-Reply-To: <20170622232156.vptuoafdtglokujw@sigill.intra.peff.net> (Jeff
        King's message of "Thu, 22 Jun 2017 19:21:56 -0400")
Message-ID: <xmqqshirffay.fsf@gitster.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Jeff King <peff@peff.net> writes:

>> +You don't need to be subscribed to the list to send mail to it, and
>> +others on-list will generally CC you when replying (although some
>> +forget this). It's adviced to subscribe to the list if you want to be
>> +sure you're not missing follow-up discussion, or if your interest in
>> +the project is wider than a one-off bug report, question or patch.
>> +
>>  The maintainer frequently sends the "What's cooking" reports that
>>  list the current status of various development topics to the mailing
>>  list.  The discussion following them give a good reference for
>
> You perhaps already read it, but you may want to steal wording or
> suggestions from the mailing list section at:
>
>   https://git-scm.com/community
>
> which is covering the same ideas (and vice versa, patches to that page
> are welcome if the README says something better).

OK, so... Ăvar's version does not mention:

 - text/plain, which is a very good addition.

 - note about CC in a way as useful as the "community" page does,
   which may want to steal from the latter.

 - the archive, but it may not be needed in the context of this
   document.  "Read the archive to make sure you are not repeating
   somebody else said before speaking" is something we silently wish
   everybody to follow, but it is something we do not want to say
   out loud, especially to new people.

 - Windows, but I am not sure if it is necessary or even healthy.
   One thing I would rather not to see is the Windows mailing list
   becomes the first line triage place for any and all issues that
   were experienced by a user who happened to be using Windows, and
   majority of the issues turn out to be unspecific to Windows.  I'd
   suspect that all of us rather would want to see the referral go
   the other way around.

Otoh, "community" page does not encourage subscription as a way to
ensure you'll see follow-up discussion, which may be a good thing to
add.

A tangent I just found funny is this paragraph on the "community"
page:

    The archive can be found on public-inbox. Click here to
    subscribe.

Of course clicking does not take you to a subscription page for
public-inbox, even though the two sentences appear to be related.

Perhaps swap the order of the two, like so, with a bit richer
explanation taken from Ăvar's version:

	... disable HTML in your outgoing messages.

	By subscribing (click here), you can make sure you're not
	missing follow-up discussion and also learn from other
	development in the community.  The list archive can be found
	on public-inbox.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 71A1B20401
	for <e@80x24.org>; Fri, 23 Jun 2017 06:59:00 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754530AbdFWG65 (ORCPT <rfc822;e@80x24.org>);
        Fri, 23 Jun 2017 02:58:57 -0400
Received: from mail-ua0-f182.google.com ([209.85.217.182]:33137 "EHLO
        mail-ua0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754467AbdFWG65 (ORCPT <rfc822;git@vger.kernel.org>);
        Fri, 23 Jun 2017 02:58:57 -0400
Received: by mail-ua0-f182.google.com with SMTP id 70so32092113uau.0
        for <git@vger.kernel.org>; Thu, 22 Jun 2017 23:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-transfer-encoding;
        bh=Ea4zJonZg9tbwMrE6tSeHdf8nmJ/1f6I+816LDboHxk=;
        b=di6UHAXVqQK86ukpG7TNgeeHMJA5oFrf3rDcArjCgj5egc6OgQl+Xsdp7FafvlJtoJ
         zdkOb+HsMP/i+wmUQguooKTfO669J6f6Zdzj+Omrov93Whf2i6K+RnvTDzLGNxIrcDL+
         WcNmv8aYQqiDeVyl/lIo08UawbQQgEYx0CsYWZrqay1mePtu/WcO/bikzTU/C52/wV2p
         6gL8g550pOIafBMF9bKPqn/21ULc7DvjmJyiVvStzR97viU4wd9K7trVg7U6OaAdY/kX
         +c0zH9Icmd0C4+Tz5Y/s0nArOlctjcFQVWnsNW2PJY1IfbOz71UWQjsxDX8c8x+zjK60
         hnWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=Ea4zJonZg9tbwMrE6tSeHdf8nmJ/1f6I+816LDboHxk=;
        b=G3HPJfYkTYpXyZiz5tADMXrrz0XcvGXHzSrPPhmwyyMzv+WXGAiwVIGLhA+EPaiPXZ
         r8y/KETDYt2kMZdsC7uulYxRfuV59ItA/Esx002kyw4nc+dLSg0qNYCqLkU5tBJhDigO
         y4PKB8curnVw00JCtcbQidiTDC/IWBTJhMOkLQFUUCL1gzr/BLKs5n2Xw2g1Er6Jp7tG
         2HSlIeufygtmLCfLoj/fyh5t2qE5bcjiX2Aqum7g+D2uZ4OSz1NAiuDRCbbxV0nxKSfD
         SinqMakq5aPrY9q6Degd87k5x/Aq/oHYr2eEXn0Kq1XUZsDGMDbszPX/7e3pBxPVO5Dh
         tJYQ==
X-Gm-Message-State: AKS2vOxeyQXB7jtazNM0+tH2OnrEoxs+OwB6T2FQ/AgiGi69fg8PcJom
        u5BWHlNhM5ylzLQbFSjZ70hdBTGFlQ==
X-Received: by 10.159.59.143 with SMTP id r15mr5176180uah.110.1498201136125;
 Thu, 22 Jun 2017 23:58:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.184.136 with HTTP; Thu, 22 Jun 2017 23:58:55 -0700 (PDT)
In-Reply-To: <878tkjk7m7.fsf@gmail.com>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
 <20170622124803.45sduodpfbwuuq52@ruderich.org> <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
 <20170622134708.fcc4zxakga6p255x@ruderich.org> <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
 <20170622204628.eintlap4uchlncub@ruderich.org> <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
 <878tkjk7m7.fsf@gmail.com>
From:   demerphq <demerphq@gmail.com>
Date:   Fri, 23 Jun 2017 08:58:55 +0200
Message-ID: <CANgJU+Um-2CLDYYsS=acJ5udc8M2Wr9KSL3PuGAYpda0WaMmxw@mail.gmail.com>
Subject: Re: your mail
To:     =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= <avarab@gmail.com>
Cc:     Junio C Hamano <gitster@pobox.com>,
        Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git@vger.kernel.org" <git@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On 22 June 2017 at 23:58, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason <avarab@gm=
ail.com> wrote:

> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be

FWIW: "adviced" is misspelled, it should be "advised", and IMO, it
feels like poor style to begin a sentence with a contraction. Not
strictly wrong, but sufficiently informal that I think it is out of
place in docs like this. Better to just say "It is", or even just "You
are", especially as you use "you" later in the sentence.

I actually think simplifying that sentence considerably is preferable:

"To be sure you receive all follow-up mails you should subscribe to the lis=
t."

flows better and is more succinct than

"It's advised to subscribe to the list if you want to be sure you're
not missing follow-up discussion".

> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.

cheers,
yves

--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,
	T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 395A620282
	for <e@80x24.org>; Fri, 23 Jun 2017 16:54:02 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754200AbdFWQxv (ORCPT <rfc822;e@80x24.org>);
        Fri, 23 Jun 2017 12:53:51 -0400
Received: from cloud.peff.net ([104.130.231.41]:50662 "HELO cloud.peff.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
        id S1753926AbdFWQxu (ORCPT <rfc822;git@vger.kernel.org>);
        Fri, 23 Jun 2017 12:53:50 -0400
Received: (qmail 1508 invoked by uid 109); 23 Jun 2017 16:53:49 -0000
Received: from Unknown (HELO peff.net) (10.0.1.2)
 by cloud.peff.net (qpsmtpd/0.94) with SMTP; Fri, 23 Jun 2017 16:53:49 +0000
Authentication-Results: cloud.peff.net; auth=none
Received: (qmail 16046 invoked by uid 111); 23 Jun 2017 16:53:54 -0000
Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7)
    by peff.net (qpsmtpd/0.84) with SMTP; Fri, 23 Jun 2017 12:53:54 -0400
Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Fri, 23 Jun 2017 12:53:48 -0400
Date:   Fri, 23 Jun 2017 12:53:48 -0400
From:   Jeff King <peff@peff.net>
To:     Junio C Hamano <gitster@pobox.com>
Cc:     =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>,
        Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
Message-ID: <20170623165347.s6byszwdps34ntzv@sigill.intra.peff.net>
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
 <20170622124803.45sduodpfbwuuq52@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
 <20170622134708.fcc4zxakga6p255x@ruderich.org>
 <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
 <20170622204628.eintlap4uchlncub@ruderich.org>
 <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
 <878tkjk7m7.fsf@gmail.com>
 <20170622232156.vptuoafdtglokujw@sigill.intra.peff.net>
 <xmqqshirffay.fsf@gitster.mtv.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <xmqqshirffay.fsf@gitster.mtv.corp.google.com>
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:

> Otoh, "community" page does not encourage subscription as a way to
> ensure you'll see follow-up discussion, which may be a good thing to
> add.
> 
> A tangent I just found funny is this paragraph on the "community"
> page:
> 
>     The archive can be found on public-inbox. Click here to
>     subscribe.
> 
> Of course clicking does not take you to a subscription page for
> public-inbox, even though the two sentences appear to be related.
> 
> Perhaps swap the order of the two, like so, with a bit richer
> explanation taken from Ăvar's version:
> 
> 	... disable HTML in your outgoing messages.
> 
> 	By subscribing (click here), you can make sure you're not
> 	missing follow-up discussion and also learn from other
> 	development in the community.  The list archive can be found
> 	on public-inbox.

Yeah, I think that's a good suggestion. Do you want to phrase it in the
form of a patch? :)

-Peff

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD shortcircuit=no
	autolearn=ham autolearn_force=no version=3.4.0
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 1EDA520282
	for <e@80x24.org>; Fri, 23 Jun 2017 18:44:38 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754781AbdFWSof (ORCPT <rfc822;e@80x24.org>);
        Fri, 23 Jun 2017 14:44:35 -0400
Received: from mail-pg0-f41.google.com ([74.125.83.41]:36130 "EHLO
        mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754327AbdFWSoe (ORCPT <rfc822;git@vger.kernel.org>);
        Fri, 23 Jun 2017 14:44:34 -0400
Received: by mail-pg0-f41.google.com with SMTP id u62so24449233pgb.3
        for <git@vger.kernel.org>; Fri, 23 Jun 2017 11:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-transfer-encoding;
        bh=sk+TlJb6Sx+YwT99V4BnsGnq/GMakUf+jVImx6/Y9Zs=;
        b=D873iVODWZ22T7b6f6bPB5aO8gGxK7Z9ndw7kqCdQMBg2QkqZZGXzLTKgIZjJtyglE
         C8e0UQPPyN2W0vE59rAgyTJcbJINWClQxDXwKCqY2qIekYGnNNY6dGeJPfvmnuZs6hdg
         DamAj6/A1yAfaXI6psDkSBdVjz1yBxNov/gKjcnoJ9GHJg+MGyH3/0W1lxvPOGtIP2QG
         CyxnXkg19Dyq0dpUNBzqX1nlhoSnruznaO7a+dUT8bV4FFAMcuuVnNUi33KTBfT7qpda
         7FHzFVaYvAGOyHoVhOre/IKIsYWrSl3+vuZBsORjc11quQcAuFH/tPevtdNxeKWTl+uy
         EfCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:sender:from:to:cc:subject:references:date
         :in-reply-to:message-id:user-agent:mime-version
         :content-transfer-encoding;
        bh=sk+TlJb6Sx+YwT99V4BnsGnq/GMakUf+jVImx6/Y9Zs=;
        b=PdXJ+DiT3nL1zNVxf/yGIEh7D6KePZBgeSbbasS+pwziTMdAxGo4CTbcR67Pk7ntp3
         pyviYYCuKbIwgLGHWEJmb83nptPmvm7tZnRVmxYp4N5dcE3EnGbTBNr3bBpQWjPqCYD8
         JQoSgMSjSW/DMihkPnbzptwD6KR/ntxc18/MXAT89asySRoKtyoniFgzCCyTWraeYvbZ
         9n/hl6Nxx7R9MHNkJ6AwlAd7VoTPhXq/P3jyFpgZQGkagGfRQoOeFxLVkYnNNQIiCk4X
         9q6f0b9Y6RXuIGc3CiCFZRbqbol4ruH7+K3z4elOnvCvOmaZijBMAqgAZW99IRraBaVw
         P5nQ==
X-Gm-Message-State: AKS2vOyywoDJ9xs1MiYH5QeSM6Yw5lJFN1lJeVnr7vDxske6tieC7mj5
        vSaBFhOA2WoE0g==
X-Received: by 10.84.128.67 with SMTP id 61mr10907651pla.246.1498243474088;
        Fri, 23 Jun 2017 11:44:34 -0700 (PDT)
Received: from localhost ([2620:0:1000:8622:4cd0:d6d2:1e09:4052])
        by smtp.gmail.com with ESMTPSA id f8sm11746748pfc.14.2017.06.23.11.44.33
        (version=TLS1_2 cipher=AES128-SHA bits=128/128);
        Fri, 23 Jun 2017 11:44:33 -0700 (PDT)
From:   Junio C Hamano <gitster@pobox.com>
To:     Jeff King <peff@peff.net>
Cc:     =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason <avarab@gmail.com>,
        Simon Ruderich <simon@ruderich.org>,
        Patrick Lehmann <Patrick.Lehmann@plc2.de>,
        Jessie Hernandez <git@jessiehernandez.com>,
        "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: your mail
References: <7c277ac1cfb40b9b362d468a94dfb4fe.squirrel@mail.jessiehernandez.com>
        <20170622124803.45sduodpfbwuuq52@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A3D5@SBS2011.opfingen.plc2.de>
        <20170622134708.fcc4zxakga6p255x@ruderich.org>
        <0092CDD27C5F9D418B0F3E9B5D05BE080102A423@SBS2011.opfingen.plc2.de>
        <20170622204628.eintlap4uchlncub@ruderich.org>
        <xmqq8tkjiu3d.fsf@gitster.mtv.corp.google.com>
        <878tkjk7m7.fsf@gmail.com>
        <20170622232156.vptuoafdtglokujw@sigill.intra.peff.net>
        <xmqqshirffay.fsf@gitster.mtv.corp.google.com>
        <20170623165347.s6byszwdps34ntzv@sigill.intra.peff.net>
Date:   Fri, 23 Jun 2017 11:44:32 -0700
In-Reply-To: <20170623165347.s6byszwdps34ntzv@sigill.intra.peff.net> (Jeff
        King's message of "Fri, 23 Jun 2017 12:53:48 -0400")
Message-ID: <xmqqvanmee7j.fsf@gitster.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Jeff King <peff@peff.net> writes:

> On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
>
>> Otoh, "community" page does not encourage subscription as a way to
>> ensure you'll see follow-up discussion, which may be a good thing to
>> add.
>> 
>> A tangent I just found funny is this paragraph on the "community"
>> page:
>> 
>>     The archive can be found on public-inbox. Click here to
>>     subscribe.
>> 
>> Of course clicking does not take you to a subscription page for
>> public-inbox, even though the two sentences appear to be related.
>> 
>> Perhaps swap the order of the two, like so, with a bit richer
>> explanation taken from Ăvar's version:
>> 
>> 	... disable HTML in your outgoing messages.
>> 
>> 	By subscribing (click here), you can make sure you're not
>> 	missing follow-up discussion and also learn from other
>> 	development in the community.  The list archive can be found
>> 	on public-inbox.
>
> Yeah, I think that's a good suggestion. Do you want to phrase it in the
> form of a patch? :)

OK. Letme try.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id C91BF1F453
	for <e@80x24.org>; Fri, 25 Jan 2019 11:27:47 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726252AbfAYL1q (ORCPT <rfc822;e@80x24.org>);
        Fri, 25 Jan 2019 06:27:46 -0500
Received: from ikke.info ([178.21.113.177]:53076 "EHLO vps892.directvps.nl"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726049AbfAYL1q (ORCPT <rfc822;git@vger.kernel.org>);
        Fri, 25 Jan 2019 06:27:46 -0500
Received: by vps892.directvps.nl (Postfix, from userid 1008)
        id CE1654400DB; Fri, 25 Jan 2019 12:27:44 +0100 (CET)
Date:   Fri, 25 Jan 2019 12:27:44 +0100
From:   Kevin Daudt <me@ikke.info>
To:     Furkan DURUL <furkaandurul@gmail.com>
Cc:     git@vger.kernel.org
Subject: Re: your mail
Message-ID: <20190125112744.GB14639@alpha>
References: <CAL9vGGXKTx26K+ntscx32UeGzabgAnDeNGpuvCefubX4YHyvsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9vGGXKTx26K+ntscx32UeGzabgAnDeNGpuvCefubX4YHyvsQ@mail.gmail.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Fri, Jan 25, 2019 at 12:47:35PM +0300, Furkan DURUL wrote:
> Hello,
> My name is Furkan. I'm a new graduated Electronics and Communication
> Engineer in Turkey. In my current workplace, we use Git in all our
> projects and I really learned a lot from your Pro Git Book. I would
> like to contribute to translation of this book to Turkish. I'm also a
> freelance translator and have experience about translation.
> Look forward to hear you
> Cheers

Hello Furkan,

Welcome to the community. Pro Git is not maintained by the git
community, but is a separate project.

You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].

Kind regards, Kevin


[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,
	SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham
	autolearn_force=no version=3.4.2
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id B1CB91F461
	for <e@80x24.org>; Thu, 11 Jul 2019 20:18:12 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729037AbfGKUSL (ORCPT <rfc822;e@80x24.org>);
        Thu, 11 Jul 2019 16:18:11 -0400
Received: from ikke.info ([178.21.113.177]:40714 "EHLO vps892.directvps.nl"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726207AbfGKUSL (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 11 Jul 2019 16:18:11 -0400
Received: by vps892.directvps.nl (Postfix, from userid 1008)
        id 1CF194400A7; Thu, 11 Jul 2019 22:18:10 +0200 (CEST)
Date:   Thu, 11 Jul 2019 22:18:10 +0200
From:   Kevin Daudt <me@ikke.info>
To:     Robert Morgan <robert.thomas.morgan@gmail.com>
Cc:     git@vger.kernel.org
Subject: Re: your mail
Message-ID: <20190711201810.GE8180@alpha>
Mail-Followup-To: Kevin Daudt <me@ikke.info>,
        Robert Morgan <robert.thomas.morgan@gmail.com>, git@vger.kernel.org
References: <CAMgm5nNRYQpjFeDA=tLZax_vdn4F1nxH4EgbbLY0or7dnYG2Hg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMgm5nNRYQpjFeDA=tLZax_vdn4F1nxH4EgbbLY0or7dnYG2Hg@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git

You need to send this to majordomo@vger.kernel.org. Sending it to the
git mailing list will not do a lot.

Kevin

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <git-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,
	SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham
	autolearn_force=no version=3.4.2
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by dcvr.yhbt.net (Postfix) with ESMTP id 3BE3C1F461
	for <e@80x24.org>; Thu, 11 Jul 2019 20:25:36 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729010AbfGKUZf (ORCPT <rfc822;e@80x24.org>);
        Thu, 11 Jul 2019 16:25:35 -0400
Received: from mail-io1-f48.google.com ([209.85.166.48]:33432 "EHLO
        mail-io1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726207AbfGKUZf (ORCPT <rfc822;git@vger.kernel.org>);
        Thu, 11 Jul 2019 16:25:35 -0400
Received: by mail-io1-f48.google.com with SMTP id z3so15530979iog.0
        for <git@vger.kernel.org>; Thu, 11 Jul 2019 13:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=RgjuwyTtDG3jBXsCT6adEsZD7+6FsUZ3ifqo2sADZiI=;
        b=FHEXssNiJHCPZKc3ng2eBN5kv1ljcwIF+tNKgfqVa6kvdje4DYr+h1bJ2iBm3t3Pcp
         U+vMEN0jjAGJMEJ4XOsOiLvnONNgHHJzU7WzufC3uP3esahKKWB+g5M4al3NpVqaP4qR
         ikV2nwTwYHlH/QglDd0NG6KU49KnfAzTJiKgHyOMUA0MyBDHDd5AlYLddxd02YyuVHAv
         qg83WiYQxkL9E/CSE5nquBee4hwivqNyUxgJCszPjS1Fxqn5V1E0z3piPzx5lWqIwNio
         UDA8E28tw/J7+ty7VSPDe3AcbaJ0H6WMUotvW701Sgmc26iIy4yMjJDdV41cHY8NfHuD
         FwJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=RgjuwyTtDG3jBXsCT6adEsZD7+6FsUZ3ifqo2sADZiI=;
        b=kkcJqQwpAI2tRQkpXTH/ND0z7+cmxvWpsVJ8OQmbH8oe6JJclYhksKOti+Esu8KmM3
         8eGrMWpxxFMMjXquCBfzB4PzDl2C8K9HdALFbiIqKL0SQ8lYQzC7ZqGU/GqjXeh7QRBL
         DzbC+5eJzt48XqWgKMgvcOWfukcSJwv64D+wfwXWJ7CPTpziS+dmvIO41GzAcxQFQmCJ
         2feG+lLYLbFMIO7jXpp7Db8JkqX4oTnFCGAGzN4JIc+PSup/CnIuoyOyS3472+kVgSqi
         tey47iim1NVj/QhE320hRD+2YPuSgM2tHE70mRGUr/odjWRhNWRnOay9s8HZyac4b+D7
         NijQ==
X-Gm-Message-State: APjAAAV965HjfP97pEuEyFSQml7br5y6XBLCB2RJH2e+i6J0GuXUcFCD
        cMRriCWydarGoYbKrJFK5AmvjInl6Ky+4d68w2D2Hw==
X-Google-Smtp-Source: APXvYqxwllrjgnnTlnwF4QwLE+FWyIzJbNzf065/lvIxblV63hv5JIXnyOBTpp78+jFJm2kFIvhxIU+QxqbCJztHlN0=
X-Received: by 2002:a5d:8451:: with SMTP id w17mr6818490ior.226.1562876734063;
 Thu, 11 Jul 2019 13:25:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAMgm5nNRYQpjFeDA=tLZax_vdn4F1nxH4EgbbLY0or7dnYG2Hg@mail.gmail.com>
 <20190711201810.GE8180@alpha>
In-Reply-To: <20190711201810.GE8180@alpha>
From:   Robert Morgan <robert.thomas.morgan@gmail.com>
Date:   Thu, 11 Jul 2019 15:25:23 -0500
Message-ID: <CAMgm5nOJ2jYAKE38XwBMMbLUfryj_W=kUQn1iG4fgQQPR3wS0g@mail.gmail.com>
Subject: Re: your mail
To:     Kevin Daudt <me@ikke.info>,
        Robert Morgan <robert.thomas.morgan@gmail.com>,
        git@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Apologies list!  Thanks Kevin.  That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.

Robert


On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt <me@ikke.info> wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
> You need to send this to majordomo@vger.kernel.org. Sending it to the
> git mailing list will not do a lot.
>
> Kevin

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=iiTG=ZM=vger.kernel.org=git-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,
	SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 148DFC432C0
	for <git@archiver.kernel.org>; Wed, 20 Nov 2019 05:30:17 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id D23F42245F
	for <git@archiver.kernel.org>; Wed, 20 Nov 2019 05:30:16 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=ttaylorr-com.20150623.gappssmtp.com header.i=@ttaylorr-com.20150623.gappssmtp.com header.b="HtIrmC+y"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726220AbfKTFaP (ORCPT <rfc822;git@archiver.kernel.org>);
        Wed, 20 Nov 2019 00:30:15 -0500
Received: from mail-pj1-f42.google.com ([209.85.216.42]:45045 "EHLO
        mail-pj1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725832AbfKTFaP (ORCPT <rfc822;git@vger.kernel.org>);
        Wed, 20 Nov 2019 00:30:15 -0500
Received: by mail-pj1-f42.google.com with SMTP id w8so3645547pjh.11
        for <git@vger.kernel.org>; Tue, 19 Nov 2019 21:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ttaylorr-com.20150623.gappssmtp.com; s=20150623;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to:user-agent;
        bh=x10QfBKlTmeavuHfm82zKCh75xYT/cAWeMo2v+h62J8=;
        b=HtIrmC+yrvlKhnxgm6BiIuFvviLIo6DHhhJDxCoUvVsibxZfHicV8PBjGbW8DIUMdU
         CMLFKWNXgzMypr0Rq7hK64+7LiegnoJc8k4Fosd6eGSNHj7Y2E523w6rjo5mLrsaxicp
         DWEfQydgfSMVnrPkfhRAOzoIDxXQj3V4sO0SSnScBjBokW1yPRZDl+TY2UVKGzGT3LHp
         9CJnfe1tGOnMB6RxzZuM4gKkT3BEEnx4uAWB19nBv2hlGAsZDceS6Op1BuSAfFmyRHZq
         wWaxNC/FUDN72GosF/XblCNXWxNrhGhecVpWjOxjr+A/R3kqEsQNlB2OyMQ/bdhXtih2
         gcMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to:user-agent;
        bh=x10QfBKlTmeavuHfm82zKCh75xYT/cAWeMo2v+h62J8=;
        b=BUr7YeIQR38yUfC87MPDdrbZGLWNnTzqe7BjAIlSArZ56Z1ARxJQrmlErJ7xXFfdzb
         rwDZ7TLK0dFHgeJtqZloPPeWp32gW4SXO0FuCU+Su+v5AfxBMvHTgnwVdo9q10lgDaYi
         etAYm3Zqnbma+d0SOwOXpxRbNVin5Ll8AcodhBrzM3Dk7m9f97viOC5o8OS06h05Lx4A
         pTXDEDmNreIQnk5QgmFcDOJoEIFpkYjHJS1LoeTXwhz5mgaBYEcF7GRHq2tdtjiGkZ76
         49x/HCkGK7feKimgg0LAVh/kBu7qoTvLOpApjonH44hL9+d1mr4a5VG0nNFFttjIYu/3
         GCDg==
X-Gm-Message-State: APjAAAXzL9099YyfDoWzjjkgOP9uzCLRIFlYz3Qyjec+1nU4Gc+BWhs0
        ycC8AmSC3BlfO5VfJ3yHvdCCrA==
X-Google-Smtp-Source: APXvYqxs/005zm4guj46m+DL97CQPq85axbYe6CGNUKwhQx63LLWlBhQmih12CF6cWDgwZmqT6UDMg==
X-Received: by 2002:a17:90a:c2:: with SMTP id v2mr1728769pjd.140.1574227812762;
        Tue, 19 Nov 2019 21:30:12 -0800 (PST)
Received: from localhost ([2601:602:9200:32b0:44ca:eab6:8a88:b2d7])
        by smtp.gmail.com with ESMTPSA id d23sm28106738pfo.140.2019.11.19.21.30.11
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 19 Nov 2019 21:30:11 -0800 (PST)
Date:   Tue, 19 Nov 2019 21:30:11 -0800
From:   Taylor Blau <me@ttaylorr.com>
To:     Han-Wen Nienhuys <hanwen@google.com>
Cc:     git <git@vger.kernel.org>,
        Christian Couder <christian.couder@gmail.com>,
        Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: your mail
Message-ID: <20191120053011.GA41291@syl.local>
References: <CAFQ2z_OMr4J-gF1HXXkSQFheiDkf+7WBbn-oLYeDydmuLSfN1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAFQ2z_OMr4J-gF1HXXkSQFheiDkf+7WBbn-oLYeDydmuLSfN1w@mail.gmail.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Hi Han-Wen,


On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> Hey folks,
>
> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153

Very exciting, and thanks for your work on this. I haven't taken a
close look at the code yet, so I'm sure taking this further involves a
much more careful examination.

I know that Christian Couder (who you CC-d on this thread) was also
working on this for either GitLab or Booking.com.

Christian -- are you still working on this for either one of those
entities? If so, is there some way to unify these two efforts?

> cheers!
> --

Thanks,
Taylor

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=iiTG=ZM=vger.kernel.org=git-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,
	SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 88DE9C432C0
	for <git@archiver.kernel.org>; Wed, 20 Nov 2019 08:06:09 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 4EFF321852
	for <git@archiver.kernel.org>; Wed, 20 Nov 2019 08:06:09 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QQNdX0Lh"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1727330AbfKTIGI (ORCPT <rfc822;git@archiver.kernel.org>);
        Wed, 20 Nov 2019 03:06:08 -0500
Received: from mail-ed1-f54.google.com ([209.85.208.54]:38142 "EHLO
        mail-ed1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726358AbfKTIGI (ORCPT <rfc822;git@vger.kernel.org>);
        Wed, 20 Nov 2019 03:06:08 -0500
Received: by mail-ed1-f54.google.com with SMTP id s10so19507659edi.5
        for <git@vger.kernel.org>; Wed, 20 Nov 2019 00:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=5W8p4+ODgYEBKQokoynQLSCR6cQP47+Vt+GhaNTde7w=;
        b=QQNdX0LhGQMpZlE4k4VEosNSIN0aiqPSUfkgr0ILqLPbu3Gvwobrwvs6377XqEw0Jt
         KdjWrEC/EIXbU9YvSEy5XIKOFzxeQtyli5oU02T6YO5SrcXvLmVqT+kuHD/lebolidQ3
         CHPa5o++YOi0ciFw8FGHpXVrlOGbAKYQqLLiuQBry1IAh8AmbIfe3vE7nLD7k+zgqR5b
         58rl3iivfpTOH5TFNQ3ljZTHhq+JKsAcBzs8kxFkPvKRkdC1COvsLtZ+Og4tWQl3Xds3
         UnyeM0wyPUTxnpxqo77jLfttkWlf36QTjENaqzw3xQLGTThR24Aa13VZE3In5XSpk7tl
         etCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=5W8p4+ODgYEBKQokoynQLSCR6cQP47+Vt+GhaNTde7w=;
        b=J5bFQ7fwGTwlhjaTDaRhqNkNAp5L8uqchChJ4biPUMhhb6pXrLDQlufua9Ha8QgqvL
         kzJFGlYxj16NRTPcvjXXo2lLmwHbTC5VPrsA1UBTN5k9wVlha2XoAOVH8RgQ3IU2GToW
         A8YlZYzckuXQ7GPlDGAeyHFI/O+gIVCVTUH1INo2TLq8YH1bSSlBOr4IoTot12LRMFgY
         UdJjpvU2IaFkwwrH0901f7gM2SKkOU8CrtaqA/S2rpfIPr7h4fyrVeCx1Rnl6IOZiNMP
         9kfZ9GIXoFF3XeZfn7CHKi1yCIIi63hrf3btCBr1FnMogR9PTuzNUE/nDs2VpebsKcQM
         dBGQ==
X-Gm-Message-State: APjAAAUnm6g6iwN5Vi045XT/ke080FztUSuc87bKhD5F8UztrNbNrNS/
        vVZWt63uJolnWBo56OZe7SITBMKov/HPbWHz1zm+Cpff
X-Google-Smtp-Source: APXvYqyCj6qXa6MMUTtolrw7o2tmyLBDh6RROfosVkfEUOcZbh/WPxp4TsZLIGN1cSeSurR7+sM4nfjvwGJQ2d3otpQ=
X-Received: by 2002:a17:907:447b:: with SMTP id oo19mr3417888ejb.81.1574237166252;
 Wed, 20 Nov 2019 00:06:06 -0800 (PST)
MIME-Version: 1.0
References: <CAFQ2z_OMr4J-gF1HXXkSQFheiDkf+7WBbn-oLYeDydmuLSfN1w@mail.gmail.com>
 <20191120053011.GA41291@syl.local>
In-Reply-To: <20191120053011.GA41291@syl.local>
From:   Christian Couder <christian.couder@gmail.com>
Date:   Wed, 20 Nov 2019 09:05:54 +0100
Message-ID: <CAP8UFD27ReXZ_pA3v6iwHebNBfwxuEKy4dAhPyTu0Ey=TzvCkA@mail.gmail.com>
Subject: Re: your mail
To:     Taylor Blau <me@ttaylorr.com>
Cc:     Han-Wen Nienhuys <hanwen@google.com>, git <git@vger.kernel.org>,
        Johannes Schindelin <johannes.schindelin@gmx.de>
Content-Type: text/plain; charset="UTF-8"
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org

Hi Taylor and Han-Wen,

On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > I spent the last few weeks cobbling together an implementation of the
> > reftable format in C and in Go. I thought this would be cool to add to
> > git-core, but I doubt whether I will have enough time to see such an
> > effort through. Maybe some of you would want to try integrating it
> > into the Git-core code base?  Example code is here:
> >
> >   https://github.com/google/reftable/blob/master/c/api.h#L153

Interesting!

> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?

Yeah, I started working on this last year for Booking.com, and I am
now slowly working on it for GitLab. It is not yet finished because it
has been low priority work.

I took a very quick look at Han-Wen's implementation and it looks very
different from mine from the outside. It seems more complete, but
might be less integrated into the Git code base.

Best,
Christian.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=BxWL=AF=vger.kernel.org=git-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 9637DC433DF
	for <git@archiver.kernel.org>; Wed, 24 Jun 2020 01:31:09 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 60D22206EB
	for <git@archiver.kernel.org>; Wed, 24 Jun 2020 01:31:09 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (3072-bit key) header.d=crustytoothpaste.net header.i=@crustytoothpaste.net header.b="uNOV7OER"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2388392AbgFXBbI (ORCPT <rfc822;git@archiver.kernel.org>);
        Tue, 23 Jun 2020 21:31:08 -0400
Received: from injection.crustytoothpaste.net ([192.241.140.119]:40168 "EHLO
        injection.crustytoothpaste.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S2388347AbgFXBbI (ORCPT
        <rfc822;git@vger.kernel.org>); Tue, 23 Jun 2020 21:31:08 -0400
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:b610:a2f0:36c1:12e3])
        (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits))
        (No client certificate requested)
        by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 8267860459;
        Wed, 24 Jun 2020 01:31:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net;
        s=default; t=1592962266;
        bh=XIzPqAyzrqEz7LnUaXKhMJXg8Oc6jSRxdq2VneG4G+0=;
        h=Date:From:To:Cc:Subject:References:Content-Type:
         Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC:
         Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References:
         Content-Type:Content-Disposition;
        b=uNOV7OEREdr37NUsnLjBNce/QZS+sBrnUrtXkiq9E23uabglgz+HPfDesMLWA2glz
         FT9OtT7A1jutpGRoSdMVcW0wa9ehgXjXPIbx8Az2ty7cnfBZd6DO+WCekRym8FtMYU
         wDsOC7wLJgKw5fRLTwFZJ15v8MW4tSjx9LHCQsbMK1BjAXWScmix4QfoK2zEBI4FD6
         1MAtgHEjtGDKXOYxePAzb29F7/SQ/MlfuC2zreDWbrvJeSeLtiq4p9w5bAY2q/VH5/
         aHhPIX2S6zzxlaapR1o2rofRePYM/8SjDLro5QY3Ej4GjAyDvq4XiZoG+IWSwxjhp+
         +tmdN9xxlrGVUeGrXQXkNvRAmjDr7m0OH6zEUQC1soWUx7tv6kZOVxiEDutMziowlG
         x3VUJb5gXe3qiVHpA2nqzb2VTRi3aBJewynkvU3EUpRjiUSwc5D7EiF2TmW5x7PpCr
         8H6NxxjCthaCYN23sMNjGeB0yQ1wa3GBaMMUBly8X/Nc7m5giLj
Date:   Wed, 24 Jun 2020 01:31:01 +0000
From:   "brian m. carlson" <sandals@crustytoothpaste.net>
To:     shejan shuza <shejan0@gmail.com>
Cc:     git@vger.kernel.org
Subject: Re: your mail
Message-ID: <20200624013101.GA6451@camp.crustytoothpaste.net>
Mail-Followup-To: "brian m. carlson" <sandals@crustytoothpaste.net>,
        shejan shuza <shejan0@gmail.com>, git@vger.kernel.org
References: <CABO4vy0WTYbeAiyWf7hE_4QurwH_c1wJUdU=A4FSC0uSxiEO7g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline
In-Reply-To: <CABO4vy0WTYbeAiyWf7hE_4QurwH_c1wJUdU=A4FSC0uSxiEO7g@mail.gmail.com>
X-Machine: Running on camp using GNU/Linux on x86_64 (Linux kernel
 5.6.0-2-amd64)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID: <git.vger.kernel.org>
X-Mailing-List: git@vger.kernel.org


--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2020-06-24 at 00:38:39, shejan shuza wrote:
> Hi, I have a repository with about 55GB of contents, with binary files
> that are less than 100MB each (so no LFS mode) from a project which
> has almost filled up an entire hard drive. I am trying to add all of
> the contents to a git repo and push it to GitHub but every time I do
>=20
> git add .
>=20
> in the folder with my contents after initializing and setting my
> remote, git starts caching all the files to .git/objects, making the
> .git folder grow in size rapidly. All the files are binaries, so git
> cannot stage changes between versions anyway, so there is no reason to
> cache versions.

What you're experiencing is normal; storing files in the .git directory
is how Git keeps track of them.  It can't rely on the copies in your
working tree because you can modify those files at any time, and if you
did so, relying on them would corrupt the repository.

Also, note that Git can and does deltify changes between revisions once
the data is packed, regardless of whether the file is binary, but how
well it does so depends on your data.  For example, if it's compressed,
it likely doesn't deltify very well, so storing things like compressed
images or zip files using deflate is generally going to result in a
bloated repository.

However, if you don't need versioning for these files, then you don't
need a Git repository.  Git is a tool for versioning files, not a
general storage mechanism.  You may find a cloud storage bucket or some
other artifact storage service may meet your needs better.

I will also tell you from a practical point of view that almost nobody
(including you) will want to host a 55 GB repository filled with binary
blobs.  Usually repacking these repositories is very expensive,
requiring extensive CPU and memory usage for a prolonged time for little
useful benefit.

> Is there any way, such as editing the git attributes or changing
> something about how files are staged in the git repository, to only
> just add indexes or references to files in the repository rather than
> cache them into the .git folder, while also being able to push all the
> data to GitHub?

This is how Git LFS and similar tools, like git-annex, work.  Git LFS
will create copies of the objects in your .git directory though, at
least until they're pushed to the server, at which point they can be
pruned.  Git LFS has the same limitation as Git here.  I'm less familiar
with git-annex, but it is also a popular choice.

However, as mentioned, it sounds like you don't need versioning at all,
so unless you do, Git with Git LFS will be no more suitable for this
than plain Git.  If that's the case, I encourage you to explore
alternate solutions.
--=20
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.20 (GNU/Linux)

iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCXvKs1QAKCRB8DEliiIei
gbdwAP90zUbX2/iMiaOAKsqhdBZ4DzuYETSMaAgXOpMIYS9gAQD+P4Bi4YECJqtz
qLEw+NFLqNxDC/+Jf7DWkQdkAmDv2gM=
=IalQ
-----END PGP SIGNATURE-----

--17pEHd4RhPHOinZp--

