From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11564C3DA59 for ; Mon, 22 Jul 2024 14:54:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A09F6B0089; Mon, 22 Jul 2024 10:54:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 851306B008A; Mon, 22 Jul 2024 10:54:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 718956B008C; Mon, 22 Jul 2024 10:54:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 53A0D6B0089 for ; Mon, 22 Jul 2024 10:54:39 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 172BD14194E for ; Mon, 22 Jul 2024 14:54:39 +0000 (UTC) X-FDA: 82367685078.02.47057B3 Received: from greygoose-centos7.csh.rit.edu (greygoose-centos7.csh.rit.edu [129.21.49.170]) by imf16.hostedemail.com (Postfix) with ESMTP id 471BA180026 for ; Mon, 22 Jul 2024 14:54:37 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=rit.edu (policy=quarantine); spf=none (imf16.hostedemail.com: domain of mstrodl@freedom.csh.rit.edu has no SPF policy when checking 129.21.49.170) smtp.mailfrom=mstrodl@freedom.csh.rit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721660040; a=rsa-sha256; cv=none; b=uJkaMKeXgbDzeVOPV6r/GGDH5wGnaDRtk5dnGyd4XrPygxpSvFrFy2WCzw/noROzw5ClMD 3F/ZCnNbRYavcQ8eExdfnzQGiMnKgFUwh76kLeRQr9wmXr6YYIHB9cbXGYJpa/xv3k/jpD DqYbA7YP883iag75kL163FySUP38F4I= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=rit.edu (policy=quarantine); spf=none (imf16.hostedemail.com: domain of mstrodl@freedom.csh.rit.edu has no SPF policy when checking 129.21.49.170) smtp.mailfrom=mstrodl@freedom.csh.rit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721660040; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=r260F2Xl37oIGQIACcCpiElBJU7s/mlo4ZgNLXp+7Wk=; b=DI5TS2krExRDUrJSBUGfCozu0yFL0HXnzKjaYGfaQmjqDgIpiGS8mgux4JmJzhcK24S8xg e4djNmWGiFs9RJH2ZotZ+uc3pdiR/jYzzZPa6pg8/faO9EbIIp2EaI6rhuNezci2N0ctoB fZ7Wq6itwj0NfT4xtZhl0j3w/wfz6bo= Received: from localhost (localhost [127.0.0.1]) by greygoose-centos7.csh.rit.edu (Postfix) with ESMTP id 1194F40D7C93; Mon, 22 Jul 2024 10:54:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at csh.rit.edu Received: from greygoose-centos7.csh.rit.edu ([127.0.0.1]) by localhost (mail.csh.rit.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k_4pUcb4fZ1y; Mon, 22 Jul 2024 10:54:35 -0400 (EDT) Received: from freedom.csh.rit.edu (freedom.csh.rit.edu [129.21.49.182]) by greygoose-centos7.csh.rit.edu (Postfix) with ESMTPS id 9BA2A45735E9; Mon, 22 Jul 2024 10:54:35 -0400 (EDT) Date: Mon, 22 Jul 2024 10:54:34 -0400 From: Mary Strodl To: Rudolf Marek Cc: Christian Gmeiner , Andrew Morton , Matthew Wilcox , Christoph Hellwig , Mary Strodl , linux-kernel@vger.kernel.org, urezki@gmail.com, linux-mm@kvack.org, lee@kernel.org, andi.shyti@kernel.org, linux-i2c@vger.kernel.org, s.hauer@pengutronix.de Subject: Re: [PATCH 1/3] mm: vmalloc: export __vmalloc_node_range Message-ID: References: <20240718143103.82e33c556b2d1b6145ae43e0@linux-foundation.org> <20240718143924.43e22f68cf639b064a83f118@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 471BA180026 X-Stat-Signature: g4z1ead15tm39woy9m8fsy7s1h69anrm X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam-User: X-Rspam: Yes X-HE-Tag: 1721660077-326778 X-HE-Meta: U2FsdGVkX1/Jnh/Ov8vWxOriCMGMCWxvswsb6yzWX9tLLQSQorm62uOUcLuUAaBk6OvcZV5Q500dYeje0grIwgpNT4mRdHWXFXy6rFZgbYpK23rwSwhpGPlHWnlnd5NVnNPexxYps/5dXnljrWpAyn5zMdXe2HmO0QyZ3GJndVioyYxA6Ak6HbiCdpOSaUhAbtK5nW40pswjZKsDHsUz6bUz20/ddwjbVtBk32m1CZrooM/ZzLmpAs/RwZIMr7oDFM3wRRBgY3a1zIDLHqfJsogr5ovSG1Zjwibjf8doqQQzF62jXUyyHYj8P2dMs88YOB+XZye49I5voHMEVU2VBI8A6n4GxcfCP6truH753q3HLTPrecO20clyI5ryDQwwJbNXAVgCamltrTKtWBs5Ymd2QX7YaY1P8uiCEueuZOapktENdllPbDY5z5wAHNGqhphc94AwSGYhLc7lFysyj+4iTnBwPcUR2ShYo4pTtr4Z4oxueJkPKRnKmAujty2ROwD22aUqMqP/dGw6VC6G3TRF9uta8aVEpXuPm6WfrpTTDR/uNNelrmZJimfcKFxbmNN2p2mo/kTu7e+X8d0Bra/giejA1YM9bIoU5y13Jg9W6Sz7e0uenE1KoJHHHUKn98581T/8jrxO8USfnvkIE6EpJ7uWnA6pYTCbWWvpCeWbiLadDAjetb3Elw7ap6+Jf51dcPoCySG6FkTX6YQBPxY46Y6cOPhc7sKYVFwS5MydCF6sZ7J2+EJuztYe2bpLclBkfFVbhWhhsASqDXJ7hZedOKY4iTksnc0lMicwmEoOL5gp5GEz4JkWiQmHOuN2i8dLPSdtjdXveZp4tBDDBk741s2anDoUXDgaIUNTIWuvenQ01wJNvLPUHV3mdkdWwcWVaaJwhz5QGUTqDT6FeCDqpkD6bi87OKErEm89k1Ewlp/ZX6xVrNQegS0LaQ1fnuxqVd6LLClqQ/h8yVa bJJNYseS MlhhCVS2ipY9SvmebM/DElNTcrSetw0gSFRBr7tAeQ1oDCzYMrmmvZg+/slIF6fHbAVXhzWivhhTb6zWIwBU8r1VvO9F2Ea0UJzOCwAIcC6UsyZIPLa3dxjlJaXpT4mnCoCq/yliZOtRlu5rHyL1Czcody9ljqaLmlCgCm1veojE740pS3Bx1dlJmF22DkrxLuo3yKJ6fD8+6XFvkszi0Qg3oNxTW/wLaPvhUy0ZmrmmSaCCnh0wMWlrHy7WSSdrtOn0j X-Bogosity: Ham, tests=bogofilter, spamicity=0.000122, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jul 19, 2024 at 09:59:37PM +0200, Rudolf Marek wrote: > I would suggest to simply run the BIOS code of this interface in usermode. Sort of similar to VM86 VESA stuff. > Last time I looked into this it used STI/CLI/RDMSR/WRMSR and couple of I/O ports and cf8/cfc for PCI. I took a look at uvesafb (which appears to be what you were talking about) and it looks like it starts a separate executable and uses some IPC to talk to it. Is that the best way to do it? I guess it would look something like: - driver gets loaded - driver spawns /sbin/cgeb-helper - driver uses cn_netlink_send to send the `high_desc` to helper Then the calls to `board->entry` in the driver get replaced with `cn_netlink_send` with a `cgeb_fps`. When the userspace helper gets the message with the `cgeb_fps`, it calls into the bios code and replies to the driver with send() and passes back cgeb_fps. >From there, a callback registered with cn_add_callback will pick up the message and call `wake_up_interruptible` to send the message back to the `cgeb_call` caller. Is this what you were imagining? Or is there a simpler way to do it? Where should the code for the userspace helper live? The vesa stuff appeared to be out of tree.