From: Javier Martinez Canillas <javierm@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Borislav Petkov <bp@alien8.de>, Daniel Vetter <daniel@ffwll.ch>,
Dave Hansen <dave.hansen@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"H. Peter Anvin" <hpa@zytor.com>, Helge Deller <deller@gmx.de>,
Ingo Molnar <mingo@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols
Date: Sun, 02 Jul 2023 12:19:37 +0200 [thread overview]
Message-ID: <87pm5aaa4m.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <CAMuHMdWLRBePox24kBHBMhzKWZX2ncXCD_8JBZrWcbwo0eBZ1Q@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Hi Arnd,
>
[...]
>>
>> That would leave CONFIG_FB_DEVICE as the only user visible option
>> for DRM-only configs, which is slightly odd for the menuconfig,
>> so I still wonder if that could be done differently.
>>
>> Is there actually a point in configurations for kernels with FB=y,
>> DRM=n and FB_DEVICE=n? If we don't expect that to be a useful
>> configuration, an easier way would be to have CONFIG_FB turn it
>> on implicitly and instead have a user-visible Kconfig option
>> below CONFIG_DRM_FBDEV_EMULATION that allows controlling the
>> creation of /dev/fb*.
>
> Such a combination would allow the user to still have a text console
> on a legacy fbdev, while not having to worry about possible security
> ramifications of providing fbdev userspace access.
>
Exactly, it may be a possible combination. Not sure how useful what would
be in practice but we shouldn't restrict that IMO.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>
Cc: x86@kernel.org, linux-fbdev@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Helge Deller <deller@gmx.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols
Date: Sun, 02 Jul 2023 12:19:37 +0200 [thread overview]
Message-ID: <87pm5aaa4m.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <CAMuHMdWLRBePox24kBHBMhzKWZX2ncXCD_8JBZrWcbwo0eBZ1Q@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Hi Arnd,
>
[...]
>>
>> That would leave CONFIG_FB_DEVICE as the only user visible option
>> for DRM-only configs, which is slightly odd for the menuconfig,
>> so I still wonder if that could be done differently.
>>
>> Is there actually a point in configurations for kernels with FB=y,
>> DRM=n and FB_DEVICE=n? If we don't expect that to be a useful
>> configuration, an easier way would be to have CONFIG_FB turn it
>> on implicitly and instead have a user-visible Kconfig option
>> below CONFIG_DRM_FBDEV_EMULATION that allows controlling the
>> creation of /dev/fb*.
>
> Such a combination would allow the user to still have a text console
> on a legacy fbdev, while not having to worry about possible security
> ramifications of providing fbdev userspace access.
>
Exactly, it may be a possible combination. Not sure how useful what would
be in practice but we shouldn't restrict that IMO.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2023-07-02 10:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 21:44 [PATCH v2 0/2] Allow disabling all native fbdev drivers and only keeping DRM emulation Javier Martinez Canillas
2023-07-01 21:44 ` Javier Martinez Canillas
2023-07-01 21:44 ` [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols Javier Martinez Canillas
2023-07-01 21:44 ` Javier Martinez Canillas
2023-07-01 22:20 ` Randy Dunlap
2023-07-01 22:20 ` Randy Dunlap
2023-07-01 22:24 ` Arnd Bergmann
2023-07-01 22:24 ` Arnd Bergmann
2023-07-02 9:07 ` Geert Uytterhoeven
2023-07-02 9:07 ` Geert Uytterhoeven
2023-07-02 10:19 ` Javier Martinez Canillas [this message]
2023-07-02 10:19 ` Javier Martinez Canillas
2023-07-03 6:53 ` Thomas Zimmermann
2023-07-03 6:53 ` Thomas Zimmermann
2023-07-03 7:46 ` Javier Martinez Canillas
2023-07-03 7:46 ` Javier Martinez Canillas
2023-07-03 7:52 ` Thomas Zimmermann
2023-07-03 7:52 ` Thomas Zimmermann
2023-07-03 8:49 ` Javier Martinez Canillas
2023-07-03 8:49 ` Javier Martinez Canillas
2023-07-01 21:44 ` [PATCH v2 2/2] drm: Make fbdev emulation select FB_CORE instead of depends on FB Javier Martinez Canillas
2023-07-01 21:44 ` Javier Martinez Canillas
2023-07-01 22:06 ` Arnd Bergmann
2023-07-01 22:06 ` Arnd Bergmann
2023-07-02 9:04 ` Geert Uytterhoeven
2023-07-02 9:04 ` Geert Uytterhoeven
2023-07-02 10:17 ` Javier Martinez Canillas
2023-07-02 10:17 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pm5aaa4m.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=daniel@ffwll.ch \
--cc=dave.hansen@linux.intel.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=tzimmermann@suse.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.