back out fbdev sysfs support
PATCH 1/1 back out fbdev sysfs support
Hi Linus,
this patch backs out James' sysfs support for fbdev again. It introduces a big, race for every driver not converted to framebuffer_{alloc,release} (that is every driver but Ben's new radeonfb).
I've left in framebuffer_{alloc,release} as stubs so drivers can be converted to it gradually and once all drivers are done it can be enabled again.
<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes? A maintainers job can't be to apply patches to his personal CVS repository and sitting on them forever </rant>
drivers/video/fbmem.c +0 -6
@@ -1228,9 +1228,6 @@break ; fb_info->node = i; -if (fb_add_class_device (fb_info)) -return -EINVAL ; -if (fb_info->pixmap.addr ==NULL ) { fb_info->pixmap.addr =kmalloc (FBPIXMAPSIZE ,GFP_KERNEL );if (fb_info->pixmap.addr) {
@@ -1279,7 +1276,6 @@kfree (fb_info->pixmap.addr); registered_fb[i]=NULL ; num_registered_fb--; -class_device_del (&fb_info->class_dev);return 0 ; }
@@ -1307,8 +1303,6 @@if (register_chrdev (FB_MAJOR ,"fb" ,&fb_fops))printk ("unable to get major %d for fb devs\n" ,FB_MAJOR ); -class_register (&fb_class); -#ifdef CONFIG_FB_OF if (ofonly) {offb_init ();
drivers/video/fbsysfs.c +7 -43
71 lines not on this page · raw message
include/linux/fb.h +0 -4
@@ -448,7 +448,6 @@char *screen_base;/* Virtual address */ struct vc_data *display_fg;/* Console visible on this display */ int currcon;/* Current VC. */ -struct class_device class_dev;/* Sysfs data */ void *pseudo_palette;/* Fake palette of 16 colors */ /* From here on everything is device dependent */ void *par;
@@ -533,9 +532,6 @@/* drivers/video/fbsysfs.c */ extern struct fb_info *framebuffer_alloc (size_t size,struct device *dev);extern void framebuffer_release (struct fb_info *info); -extern int fb_add_class_device (struct fb_info *info); - -extern struct class fb_class;/* drivers/video/fbmon.c */ #define FB_MAXTIMINGS 0
Quoted 5 lines · Christoph Hellwig
<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes?
Sorry, but at this point I WOULD NOT EVEN TAKE IT ANY MORE.
That's just how I work: if somebody maintains his own tree and builds up a lot of patches, that's _his_ problem. I'm not going to replace things totally unless there is some really fundamental reason I would have to. And quite frankly, the most common "fundamental reason" is that the maintainer has not done his job.
I want controlled patches that do one thing at a time. Not a 2GB untested dump.
Quoted 3 lines
A maintainers job can't be to apply patches to
his personal CVS repository and sitting on them forever </rant>
.. and once he has patches, he can't just "dump" them out, either.
These things need to be done in a timely fashion, incrementally, one thing at a time. Anything else does not work.
And btw, for anybody who is impacted by this: you are encouraged to help. If you have a machine that works with some out-of-tree code but does _not_ work with the in-tree code, send a patch that fixes JUST THAT BUG.
Because if James can't trickle them in, somebody else will have to. That's what happened with the new radeon driver.
Linus
Quoted 10 lines · Linus Torvalds
Sorry, but at this point I WOULD NOT EVEN TAKE IT ANY MORE.
That's just how I work: if somebody maintains his own tree and builds up a lot of patches, that's _his_ problem. I'm not going to replace things totally unless there is some really fundamental reason I would have to. And quite frankly, the most common "fundamental reason" is that the maintainer has not done his job.
I want controlled patches that do one thing at a time. Not a 2GB untested dump.
Hey, that's not what I meant. Sorry for the silly language. I'm the last one to argue in favour of a single big diff. But all the driver fixes are easily separatable, in fact benh probably still has all the individual diffs for all the mac drivers.
What I meant is that the FB maintainer should try to get the existing fixes merged before adding dubious features.
Quoted 2 lines · Christoph Hellwig
What I meant is that the FB maintainer should try to get the existing fixes merged before adding dubious features.
Whilst on the subject, why does the fb code need sysfs support anyway ?
Dave
Quoted 7 lines · Dave Jones
Quoted 2 lines · Christoph Hellwig
What I meant is that the FB maintainer should try to get the existing fixes merged before adding dubious features.
Whilst on the subject, why does the fb code need sysfs support anyway ?
We want a class device so the drivers can expose some informations like the monitor probing data (EDID), allowed modes list etc... to userland.
I now have access to these infos in some drivers like radeonfb that do full monitor probing, and the fbdev "API" provides no way to get that down to userland (for use by xserver or MOL for example). I could just add some cases to the existing ioctl API, but I don't like that ;)
Ben.
Quoted 9 lines · Linus Torvalds
These things need to be done in a timely fashion, incrementally, one thing at a time. Anything else does not work.
And btw, for anybody who is impacted by this: you are encouraged to help. If you have a machine that works with some out-of-tree code but does _not_ work with the in-tree code, send a patch that fixes JUST THAT BUG.
Because if James can't trickle them in, somebody else will have to. That's what happened with the new radeon driver.
Where's James' repository, BTW? I could help with split-and-reorder on that one...
Quoted 5 lines · On Sat, Feb 14, 2004 at 05:58:13PM +0000…
Quoted 2 lines
Because if James can't trickle them in, somebody else will have to. That's what happened with the new radeon driver.
Where's James' repository, BTW? I could help with split-and-reorder on that one...
bk://fbdev.bkbits.net/fbdev-2.6
Quoted 9 lines · Linus Torvalds
Quoted 5 lines · Christoph Hellwig
<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes?Sorry, but at this point I WOULD NOT EVEN TAKE IT ANY MORE.
Quoted 8 lines
That's just how I work: if somebody maintains his own tree and builds up a lot of patches, that's _his_ problem. I'm not going to replace things totally unless there is some really fundamental reason I would have to. And quite frankly, the most common "fundamental reason" is that the maintainer has not done his job.
I want controlled patches that do one thing at a time. Not a 2GB untested dump.
I'll send you/andrew individually the drivers I control and the ones I already fixed in james tree (5 or 6 drivers)
James: The fbcon & cursor changes must get in asap. There are races that I fixed, without the changes, those races will be in 2.6.3.
Ben.
Quoted 3 lines
I'll send you/andrew individually the drivers I control and the ones I already fixed in james tree (5 or 6 drivers)
I have drivers as well which I need to send.
Quoted 2 lines
James: The fbcon & cursor changes must get in asap. There are races that I fixed, without the changes, those races will be in 2.6.3.
I just sent out a patch for people to try and look over before I submit it.
Quoted 10 lines · James Simmons
Quoted 2 lines
I'll send you/andrew individually the drivers I control and the ones I already fixed in james tree (5 or 6 drivers)
I have drivers as well which I need to send.
Quoted 2 lines
James: The fbcon & cursor changes must get in asap. There are races that I fixed, without the changes, those races will be in 2.6.3.
I just sent out a patch for people to try and look over before I submit it.
Double check with what I already commited.
Ben.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
James: The fbcon & cursor changes must get in asap. There are races that I fixed, without the changes, those races will be in 2.6.3.
I just sent out a patch for people to try and look over before I submit it.
Double check with what I already commited.
It against Linus latest tree which included your submitted changes.
Quoted 7 lines
<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes? A maintainers job can't be to apply patches to his personal CVS repository and sitting on them forever </rant>
I don't have 2GB of patches. I have way less than that. Almost every core change is in now. I'm very cautious and I rather have drivers tested for a long time.