From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@osdl.org>
Cc: Egbert Eich <eich@xfree86.org>, Jon Smirl <jonsmirl@yahoo.com>,
kronos@kronoz.cjb.net,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fbdev-devel@lists.sourceforge.net,
dri-devel <dri-devel@lists.sourceforge.net>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion
Date: 27 Oct 2003 08:10:16 -0700 [thread overview]
Message-ID: <m1isma67jb.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310251116140.4083-100000@home.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
> >
> > Speaking of XFree86: when I developed the PCI resource stuff in
> > XFree86 I was trying to get support from kernel folks to get the
> > appropriate user space interfaces into the kernel. When I got
> > nowhere I decided to do everything myself.
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
Well almost. There is still one significant flaw in the kernel space stuff.
The BIOS can specify arbitrary regions as reserved in the E820 map and then
a kernel driver can't use that region itself. This shows up in corner
cases where the resource on the PCI device is a boolean rather than
a general purpose thing. Particularly for mtd map drivers to allow
flashing your ROM from linux this is a problem.
This is not required for 2.6.0 but it would be nice to actually be able
to reliably reserve resources in kernel drivers.
Eric
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@osdl.org>
Cc: Egbert Eich <eich@xfree86.org>, Jon Smirl <jonsmirl@yahoo.com>,
<kronos@kronoz.cjb.net>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
<linux-fbdev-devel@lists.sourceforge.net>,
dri-devel <dri-devel@lists.sourceforge.net>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Date: 27 Oct 2003 08:10:16 -0700 [thread overview]
Message-ID: <m1isma67jb.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310251116140.4083-100000@home.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
> >
> > Speaking of XFree86: when I developed the PCI resource stuff in
> > XFree86 I was trying to get support from kernel folks to get the
> > appropriate user space interfaces into the kernel. When I got
> > nowhere I decided to do everything myself.
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
Well almost. There is still one significant flaw in the kernel space stuff.
The BIOS can specify arbitrary regions as reserved in the E820 map and then
a kernel driver can't use that region itself. This shows up in corner
cases where the resource on the PCI device is a boolean rather than
a general purpose thing. Particularly for mtd map drivers to allow
flashing your ROM from linux this is a problem.
This is not required for 2.6.0 but it would be nice to actually be able
to reliably reserve resources in kernel drivers.
Eric
next prev parent reply other threads:[~2003-10-27 15:10 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 2:31 DRM and pci_driver conversion Eric Anholt
2003-10-23 19:04 ` Kronos
2003-10-23 19:04 ` [Linux-fbdev-devel] " Kronos
2003-10-23 21:10 ` Eric Anholt
2003-10-23 21:31 ` Jon Smirl
2003-10-23 23:23 ` [Dri-devel] " Linus Torvalds
2003-10-23 23:23 ` Linus Torvalds
2003-10-23 23:46 ` Eric Anholt
2003-10-24 1:19 ` [Dri-devel] " Jeff Garzik
2003-10-24 1:19 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-24 1:52 ` Jon Smirl
2003-10-24 3:47 ` Multiple drivers for same hardware:, was: " Jon Smirl
2003-10-24 3:47 ` Jon Smirl
2003-10-24 4:40 ` Linus Torvalds
2003-10-24 4:40 ` Linus Torvalds
2003-10-28 18:00 ` James Simmons
2003-10-24 16:44 ` [Dri-devel] " Linus Torvalds
2003-10-24 16:44 ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-24 16:57 ` Petr Vandrovec
2003-10-24 17:59 ` Linus Torvalds
2003-10-24 17:59 ` Linus Torvalds
2003-10-24 18:34 ` Jon Smirl
2003-10-24 19:45 ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 19:45 ` [Dri-devel] Re: [Linux-fbdev-devel] " Ivan Kokshaysky
2003-10-24 19:08 ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 19:08 ` [Dri-devel] Re: [Linux-fbdev-devel] " Ivan Kokshaysky
2003-10-24 17:06 ` [Dri-devel] " Jeff Garzik
2003-10-24 17:06 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-24 1:50 ` [Dri-devel] " Jon Smirl
2003-10-24 1:50 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-25 17:29 ` [Dri-devel] " Egbert Eich
2003-10-25 17:29 ` [Dri-devel] Re: [Linux-fbdev-devel] " Egbert Eich
2003-10-25 18:37 ` Linus Torvalds
2003-10-25 18:37 ` Linus Torvalds
2003-10-25 19:17 ` [Dri-devel] " Jeff Garzik
2003-10-25 19:17 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-27 14:37 ` [Dri-devel] " Ingo Oeser
2003-10-27 14:37 ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-27 15:43 ` [Dri-devel] " Jeff Garzik
2003-10-27 15:43 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-28 10:53 ` Ingo Oeser
2003-10-27 15:14 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:14 ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-27 15:38 ` [Dri-devel] " Jeff Garzik
2003-10-27 15:38 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-27 15:50 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:50 ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-25 21:02 ` [Dri-devel] " Jon Smirl
2003-10-25 21:02 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-25 22:07 ` [Dri-devel] " Benjamin Herrenschmidt
2003-10-25 22:07 ` [Dri-devel] Re: [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-10-27 14:01 ` jlnance
2003-10-27 15:10 ` Eric W. Biederman [this message]
2003-10-27 15:10 ` Eric W. Biederman
2003-10-27 15:10 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:10 ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
[not found] ` <20031027114006.A66611@xfree86.org>
2003-10-27 19:38 ` [Dri-devel] " Ian Romanick
2003-10-27 21:32 ` Linus Torvalds
2003-10-27 23:55 ` Benjamin Herrenschmidt
2003-10-28 2:13 ` Linus Torvalds
2003-10-28 3:27 ` Philip Brown
2003-10-28 19:40 ` James Simmons
2003-10-28 21:35 ` Benjamin Herrenschmidt
2003-10-28 22:09 ` Jon Smirl
2003-10-28 22:26 ` Benjamin Herrenschmidt
2003-10-28 22:54 ` Linus Torvalds
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=m1isma67jb.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eich@xfree86.org \
--cc=jgarzik@pobox.com \
--cc=jonsmirl@yahoo.com \
--cc=kronos@kronoz.cjb.net \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.