From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: sysdev_class use from DRM
Date: Fri, 01 Jul 2005 22:23:34 +0000 [thread overview]
Message-ID: <20050701222333.GB2707@kroah.com> (raw)
In-Reply-To: <9e473391050624071263dfbea7@mail.gmail.com>
On Thu, Jun 30, 2005 at 04:55:20PM -0400, Jon Smirl wrote:
> On 6/30/05, Greg KH <greg@kroah.com> wrote:
> > > Don't tell me to merge DRM/fbdev, that fight has been going on for two
> > > years now.
> >
> > Well, that's the only real way to fix this. A simple single driver that
> > handles the pci registering and doles out the resources and callbacks to
> > the different DRM or fbdev driver is the way to go. I thought you all
> > were working on this a year ago...
>
> Merging fbdev/DRM has a lot in common with removing devfs from the
> kernel. There are numerous, vocal defenders of their rights to do
> things the way they want to.
And like devfs, those people are wrong.
Seriously, they are, and need to get over it...
> There are also major defenders of the right to hit a magic key (VT
> swap) and have a whole other set of device drivers take over the
> hardware. Every time I think a merge is going to happen somebody new
> shows up and it all falls apart.
Why wouldn't having a "control the pci device" module not allow you to
do this?
> The last round was that the fbdev drivers aren't well tested on the
> x86 (they are on other architectures). My response was, let's get some
> bug reports and fix the problems if there are any. Other people want
> to create yet a third set of drivers which avoids use of the existing
> fbdev ones.
Bah, this sucks.
Last kernel summit I thought this was all hashed out. I guess the
people not there didn't agree...
Hey, how about at KS/OLS we (anyone who cares about this) sit down and
hash it all out and produce code that does this? With a working patch,
it should be simple to get it into the tree and then everyone can move
on.
I don't want to see any silly workarounds like what you are being forced
to do to happen.
thanks,
greg k-h
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2005-07-01 22:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-24 14:12 sysdev_class use from DRM Jon Smirl
2005-06-24 19:21 ` Jon Smirl
2005-06-24 21:08 ` Dmitry Torokhov
2005-06-30 17:40 ` Greg KH
2005-06-30 20:55 ` Jon Smirl
2005-07-01 22:23 ` Greg KH [this message]
2005-07-01 23:18 ` Jon Smirl
2005-07-02 5:05 ` Greg KH
2005-07-02 13:34 ` Jon Smirl
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=20050701222333.GB2707@kroah.com \
--to=greg@kroah.com \
--cc=linux-hotplug@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).