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 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.