Become a fan of Slashdot on Facebook


Forgot your password?
Linux Software

What Will Be in Linux 2.7? 494

Realistic_Dragon writes "The first discussion has been sighted on the Linux kernel mailing list to put together a feature list of things that should go into Linux 2.7 - including hotplug CPU & Ram support, network transparent sound and improvements to Netfilter to bring it up to the the level of OpenBSD's Packet Filter. And all this before most of us have started to run 2.6.0-preX, or even a 2.6 series stable release happening. Perhaps if you have a (sensible) idea now would be a good time to voice it, otherwise you will have to wait for 2.9 to get it included."
This discussion has been archived. No new comments can be posted.

What Will Be in Linux 2.7?

Comments Filter:
  • DRM support (Score:2, Funny)

    by Anonymous Coward
    so we can play all our favorite programs and games.
  • by Nom du Keyboard ( 633989 ) on Friday October 10, 2003 @03:04PM (#7185157)
    Remove SCO from all future distributions. :^)
  • Maybe we should start working on a way to re-load the kernel without rebooting. I don't know if it's practically possible, but it certainly would be neat!
    • Two Kernel Monte (Score:5, Informative)

      by strredwolf ( 532 ) on Friday October 10, 2003 @03:12PM (#7185226) Homepage Journal te.html

      Already there.
      • te.html

        Already there.

        How about reading the web page you link to?

        As it says it only support 2.2.x + 2.3.x kernels, and only 1 cpu at that. I'd hardly describe that as "already there".

      • Re:Two Kernel Monte (Score:3, Informative)

        by caseih ( 160668 )
        This is not what the original poster was asking for. The kernel monte actually just does an effective reboot without going throug the bios. As I understand it, the kernel monte cannot tranfer running processes from one kernel to another. Last time I used it, the monte killed all my processes, and reloaded init (basically rebooting).

        What the poster wants (and what I want) is the ability to load a new kernel, transfer the existing kernel tables (process, resource, driver status, etc) over to the new kerne
    • Yes, it is possible, but I doubt it is something that we'll see in Linux anytime soon. In order to do an online kernel upgrade, you have to keep track of all the changes in the kernel's data structures. If you make a point of defining them such that they don't change between kernels (much like you define static APIs), then that's not too painful. But doing that is a lot of work, and it impacts every area of the kernel. So it's a ton of work without a huge benefit.

      Besides, it is counter to the Linux ker
    • Two-kernel-monte (info here []) will let you do that.

      The problem is that it's unlikely you'd be able to do very much when this was going on anyways. Rebooting is probably not all that much worse a solution.

      Still a nifty trick, though.

    • Try searching for kexec.
  • How about a userfriendly UI that'd let me configure everything without having to recompile eveything (or do it invisibly) just so that I can play and use without the pain and suffering that is require nowdays.

    My main gripe with Linux has been that it's a bitch to configure for things that should't be so hard. Trying to get powermanagment to work on my IBM took me months and never worked right.
  • by like_broken_records ( 710929 ) on Friday October 10, 2003 @03:08PM (#7185194)
    What Linux needs is some fatal errors. How about a screen of one solid color that comes on to warn you that all your work for the past hour is gone. You have to remember that Linux is competing with windows. If you can't beat them Join them. p.
  • by ikewillis ( 586793 ) on Friday October 10, 2003 @03:09PM (#7185204) Homepage
    is a scheduler on the same caliber as Solaris, so that the kernel can utilize multiple schedulers simultaneously. Linux currently ships with only a timeshare scheduler, but Solaris supports a number of different schedulers which can all operate simultaneously. Administrators can also move processes between different schedulers on the fly as well. A Fair Share Scheduler, for example, would be nice so that resources on large systems can be partitioned effectively as to prevent certain processes from monopolizing system resources. The CPU/RAM hotplug support would be nice... glad to see Linux trying to catch up to where Solaris was years ago. Just kidding :)
    • by paulbd ( 118132 ) on Friday October 10, 2003 @03:48PM (#7185464) Homepage

      linux doesn't only ship with a timeshare scheduler. it includes both the SCHED_FIFO and SCHED_RR schedulers, which provide close-to-real-time scheduling capabilities. most pro apps in the audio realm use one or both of these. they can both be used alongside the SCHED_OTHER ("timeshare") scheduler.

      what would be more interesting would be CPU cycle reservation, which is already present in OS X, and would be very useful for any streaming media software.

    • by photon317 ( 208409 ) on Friday October 10, 2003 @03:49PM (#7185485)

      Oh please. No doubt having had a different focus and so many years of time advantage, there are key areas where Solaris still trumps Linux. For instance, multiprocessor scalability (although it seems they sacrificed performance on 1-2 cpu boxes to acheive this result for their 64+ cpu boxes).

      However, don't ever claim that Sun's kernel is in general superior to Linux. In a lot of ways Sun's kernel is ancient and crappy compared to Linux. Take a look at Sun's IP stack versus Linux's, for instance. Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please). Or how about good integrated netfilter-like code?

      While we're on it, let's talk hardware. The price /performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons. It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI? At one point in the past 64-bit 25Mhz SBus was acceptable.... but how long did they have to delay deploying PCI on their high end systems before finally giving in?? It was nuts, and they've finally owned up and gone pretty much solid PCI-only now. Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X...
      • by ikewillis ( 586793 ) on Friday October 10, 2003 @05:17PM (#7185944) Homepage
        "However, don't ever claim that Sun's kernel is in general superior to Linux. In a lot of ways Sun's kernel is ancient and crappy compared to Linux."

        I believe the word you're looking for is mature, and immature on the Linux side. Take Linux's VM implementation, which has been scrapped and rewritten from scratch multiple times within 2.4 alone. Meanwhile the Solaris VM has been fine tuned over the past decade. Solaris's time share scheduler has been O(1) for well over half a decade, whereas Linux is just now getting an O(1) time share scheduler.

        "Take a look at Sun's IP stack versus Linux's, for instance."

        Care to tell me how Linux is superior? You seem to be only assuming it is, and leaving the burden of proof upon me. Sorry, I put it back on you.

        But just for review of some networking features: Solaris has offered stateful I/O multiplexing through the /dev/poll mechanism as well as asynchronous I/O for years. These features are only now being implemented in Linux with things like epoll(), which you'll need a 2.6 kernel and userland support in glibc to use. It will be at least a year before we can begin to expect the average Linux system to support stateful I/O multiplexing through epoll().

        Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please).

        Don't answer Solstice Disk Suite? Perhaps you forget that the LVM was modeled after the Sun Volume Manager (which later became SDS) Perhaps you'd have an argument if you were championing FreeBSD's vinum, which was modeled after the Veritas Volume Manager, however you're trying to champion a technology which mimics the Solaris implementation yet saying to discount that very implementation. Pathetic...

        "Or how about good integrated netfilter-like code?"

        Sorry, people aren't going to be using their $20,000 systems as routers for their cable modems.

        "While we're on it, let's talk hardware. The price /performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons.

        Please show me a system with better price/performance than the V440: cid=104994&parentId=48589 []

        Keep in mind that no one in their right mind is going to shell out $26,000 for a system without a warranty. The V440 comes with 3 years of parts and on-site labor.

        I'd certainly like to see you configure an equivalent system (the 1.28GHz UltraSPARC IIIi is equivalent to a 1.8GHz Opteron) from a vendor that offers at least a year of parts and on-site labor.

        "It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI?"

        The earliest Sparc systems I know of supporting PCI were Ultra 5s, released in 1995, about the same time most PC systems were starting to feature PCI.

        "Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X..."

        Unless you're talking about the Opteron, the scalability and throughput of x86 systems is severely limited by the interconnect used between CPUs. P4 Xeons essentially share the FSB between processors, greatly limiting the amount of bus bandwidth that can be simultaneously utilized by multiple processors. With the P4, keep in mind also that the P4 does not cache operations, only micro-ops in its trace cache, so whenever the trace cache becomes tainted (by, say, mispredicing a branch) the P4 must fall back on retrieving the original opcodes out of main memory, saturating the front side bus (this is why Intel has been aggressively stepping up the bus speed of the P4)

        For use as a high performance server, Linux does not rival Solaris in

      • by cybrthng ( 22291 ) on Friday October 10, 2003 @05:28PM (#7185995) Journal
        You have to be kidding right? Dump Veritas? What are you smoking? Veritas isn't just a Volume Manager/Disksuite it is a supported/planned and critical piece of your infrastructure! You rely on Veritas because you know it is tried, true and recoverable. The excellent relation of Sun and Veritas is a reason to use the platform just like Veritas on HPUX and other platforms. Your not just paying for the software, your paying for the support and paying for the mission critical needs that demand that solution. Veritas is an EXCELLENT package and nothing in linux comes close to the Veritas & Sun solutions on certified hardware. (And if you compare the linux solutions on linux certified systems with the same performance, manageability and support you get from sun i would like to see ONE vendor that can compare!)

        I also don't believe you understand the usefullness of Sun (non linux)solutions. You keep on correlating the costs to acquisition. In the real world the hardware/software costs don't mean squat. Any large IT business knows that your biggest cost is employees, software, licensing, support and contractors.

        For one, i can spend 32,000 on a 4 way 64 bit cpu machine with 8 gigs of memory, 500gb diskspace and have Hotswappable CPU's, a VASTLY supperior backplane, Vastly superior scalability in growth and a proven reliable architecture. You Can't buy ANY linux solution/Wintel solution that comes close to the Solaris/RS6000/HPUX based systems out there. As i've stated before there is only ONE vendor that offers a machine feature comparison to suns LOW END/MID RANGE v880's and it doesn't come close in comparison to power. For example the only linux enabled hot swappable cpu/backplane/intel solution is built on 4 700 mhz pentium 3 processors and costs 24,000 for the base system. My Quad 1.2ghz v880 out of the box doesn't require anything proprietary, but on the linux solution you have to run the vendors version of linux, the vendors version of the apps compiled and can only use the vendors approved addons. Sure sun is only one vendor, but solaris is solaris. There isn't a mix match of versions, releases or there isn't a version of solaris for my v880 that doesn't work on my e10k. I can grow with a common platform to support from 1 user to 65000+ users and even cluster to support from that point on.

        You have to get your mindset away from free/cheap = better. You have to realize that in the business world the costs for platforms that are tried and true is expected and also minimal compared to the costs to keep it running.

        I would rather run my 2 terrabyte financial application on a slower sun server because of the reliability, the proven architecture and HA features. You have to remember that in my case 5 minutes of downtime costs $137,000. Suddenly a $3,000 Veritas volume management solution and a $100,000 hardware platform not only is justifyable but almost even insufficient in itself if you break out the cost vs requirements ratio.

        I can make my 3 Terrabyte Clarrion System, my Sun V880 Systems, my Sun 280/240r webservers and my solaris management workstations run for months at a time in pure harmony. The fact that NOTHING CHANGES ON A WHIM IS A GODSEND!! The stability, and slowness by which things change is the reason why businesses rely on such as the costs are far from just your hardware/os purchase price.
  • ... welcome a new kernel with UMSDOS support.

    I hate my computer(s). One of them is fragmented beyond hell(beneath?), pretty impossible to repartition, and the other one is running WinXP with NTFS, oh, and I haven't got the WinXP install discs as it was already installed on the computer, COMPAQ...

    I feel like buying a new harddisk... but I'd have to buy 2 then, one for stuff stolen from RIAA/MPAA and one for Linux...
  • by Tumbleweed ( 3706 ) on Friday October 10, 2003 @03:10PM (#7185216)
    BSP/IP - "Bitch Slap Protocol/Internet Protocol" support - for remotely Bitch Slapping stupid users. An idea whose time has come(tm).

    Oh yeah, and add more SCO(tm) code - adding Evil(tm) to MS Windows(tm) sure didn't hurt the bottomline at MS(tm)! :)

    Disclaimer: (tm), (r), and (c) wherever appropriate...

    Note: BSP/IP is defensively patented by FlyByNite Industries, Inc., a wholly-owned subsidiary of Harkonnen Enterprises.
  • by peterdaly ( 123554 ) < t c> on Friday October 10, 2003 @03:11PM (#7185220)
    If the name of keeping up with the leader of the industry, I think we should integrate Mozilla. A web browser is an integral part of a modern OS.

  • When you have to patch the kernel with security updates every week?

    I think that a mechanism to patch a running kernel would improve uptime more than the ability to replace processors.

    Also, some sort of buffer overflow prevention would be cool.

    Don't know if either of these is possible... I think solaris has some sort of buffer overflow protection.
  • by rusty0101 ( 565565 ) on Friday October 10, 2003 @03:17PM (#7185253) Homepage Journal
    Disipation of excess heat via copper clad water cooling through food preparation areas, and they implement it as a kernel flag for improved overclocking processor utilization, can we start to say "Yes, Linux does include the Kitchen Sink"?
  • by strredwolf ( 532 ) on Friday October 10, 2003 @03:17PM (#7185256) Homepage Journal
    Linux Journal's May 2003 issue had an article from Rob Love about what's new in the 2.6 kernel (new VM, ALSA, improved IO subsystem, preemptive kernel) and with a few items: SCSI needs to be rewritten to make it smarter than the drivers, and the TTY code needs a rewrite -- "it's looking like to be hack."
    • the TTY code needs a rewrite -- "it's looking like to be hack."

      or, to quote Alan Cox [] (emphasis mine):
      The entire
      tty layer locking is terminally broken

      *rimshot* Thank you folks; Alan will be here all week! Remember to tip your waitress!
  • Duh (Score:3, Funny)

    by grub ( 11606 ) <> on Friday October 10, 2003 @03:17PM (#7185257) Homepage Journal

    What Will Be in Linux 2.7?

    Plenty of SCO's intellectual property, duh!
  • Soup
    Sweaters (pullover)
    Lug nuts (various sizes)
    Brie (or any other cheeses, for that matter)

    This is just a short list, but when are the developers going to get serious on these issues?

  • Shouldn't someone be maintaining a consensus list of items to be worked on - like a master feature list.
  • Kernel Sanders (Score:3, Interesting)

    by KrackHouse ( 628313 ) on Friday October 10, 2003 @03:20PM (#7185274) Homepage
    The beauty of Linux (IMO) is the ability to tweak the kernel. Why not take advantage of the fact that there is source code to be modified and make it simple for the average user to recompile the kernel? It's an ugly, ugly process right now and a lot of people are running distro kernels that aren't as optimized as they could be.
  • Unified Installer (Score:2, Interesting)

    by headkase ( 533448 )
    What I'd like to see is all the different dependancy based package managers like Red Hat's RPM system or Debian's Apt-Get be unified into a standard installer/uninstaller that all distributions can use.
    • Re:Unified Installer (Score:3, Interesting)

      by Kethinov ( 636034 )
      Damn straight. I'm a Gentoo man personally, but even portage is not a solution to this dependency hell problem. You should be able to download an RPM, double click it, and install a program without having to deal with solving dependencies manually. I really wish Linux would evolve beyond this trivial crap. It's the one thing that prevents me from recommending Linux to the average Joe (besides Gentoo's abysmal install process of course).
  • by Hubert Q. Gruntley ( 310405 ) on Friday October 10, 2003 @03:21PM (#7185279)
    FreeBSD jails rock. Root access to your own logical partition which looks and smells just like a dedicated machine, with no overhead.

    Virtual host providers can do it for free with FreeBSD, or with ~10% CPU load using User-Mode Linux.
  • by 11223 ( 201561 ) on Friday October 10, 2003 @03:25PM (#7185304)
    I've been wanting this for a while - it's time for most of the drivers in the kernel to be split out. There's no reason why the kernel sources need to be as large as they are, and there's absolutely no reason why eg sound drivers and network cards can't be maintained independently with their own build process. Tying them to kernel releases means waiting until the next release for driver improvements, can bottleneck development, and leads to the 41M(!) tarball that is 2.6test7.

    This would require setting up a decent build process for modules outside the kernel, but that's a good thing anyway. Have you tried to compile the nVidia drivers lately? It can be a pain if your kernel headers aren't quite right. If there were a decent external API and good support for building third party modules, this would also make it easier for manufacturers to supply independent drivers.
    • by Greyfox ( 87712 )
      And have it autmatically download only the correct drivers from when you configure the kernel. Now that would be cool!

      That and the BSD style jails. Those are cool too.

    • How about split out the architectures instead? Why do I have to d/l a tarball containing MIPS, SPARC, x86-64, PPC, etc. when all I want is the i386 branch?

      Since each architecture has its own branch in the tree anyway, what would prevent those from getting forked out?

    • This wouldn't work given how kernel development works. Sometimes, a core API will change, and all drivers will have to be updated. This happened recently with the taskqueue change in 2.5, and is happening again with the switch to the new driver API. It would be a royal pain to have drivers in seperate modules. Besides, nothing stops you from compiling drivers independently of your kernel. The NVIDIA and hfs+ drivers are compiled independently, for example.
    • there's absolutely no reason why eg sound drivers and network cards can't be maintained independently with their own build process

      Actually there is a practical reason why they're maintained within the kernel sources and not externally. The reason is that it allows the kernel developers more freedom to change the kernel. They don't have to worry about breaking a lot of dependent drivers because if they make a change that would break drivers, they have all the driver sources and can (and do!) go update t

  • Last time around suggestions were things that were needed to function as "real" server.

    Anyone else notice the "enlightened" comments here seem to be more aimed at matching Solaris this time around? Solaris (either purposly or not) may be put squarely in Linux's sights. Based on the track record of recent Linux developments, Sun should be worried. It's now or never to start coming up with a real business plan to address Linux. They can't consider it a "toy" for much longer and keep what little marketsha
  • a kitchen sink!
  • Linux really needs a VM. (It could also benefit from that other rumored Longhorn feature, a database-backed file system, but that's another story...).

    OK, we can add Java or Python to our systems, but this still leaves Linux-the-platform facing two big challenges:

    1. Support apps for kernel functions have to be written in lowest-common-denominator C/C++, making, say, ALSA configuration difficult

    2. The number of very different frameworks providing essential functions (desktops, config management, web server
  • Wanted: The ability to edit any answer you give during make config without having to start over
  • Hardware detection (Score:2, Interesting)

    by Brad Mace ( 624801 )
    Better hardware detection and auto-configuration would help old and new users get things running. I still can't get the scroll wheel on my stupid mouse working. Mice are simple and critical enough that they should be setup without any user intervention.

    Currently even fairly advanced users can get hung up trying to get hardware to work. Windows has a huge advantage in this area even though you usually need a cd of drivers.

    Even better would be a way to build a kernel that detects and includes support f

    • In /etc/X11/XF86Config (or /etc/X11/XF86Config-4, if you happen to be using that -- it depends on the distro and the way X was installed; you could safely perform these steps in both files, if you have both), you need the following (as well as the device line, obviously:
      • Section "InputDevice"
      • Protocol "IMPS/2"
      • Option "ZAxisMapping" "4 5"

      And that should do it, once you restart X. If this doesn't work, feel free to email me, or just post again.

  • - better and more kernel documentation! - grid technology - security reviews, leak detection systems - bridge to W32 systems - easier kernel administration, kernel admin tools
  • That would be a really cool thing to have: I've often wished I could do with sound what X lets me do with windows. But...

    Seems to me it could be done just fine in userspace -- why put it in the kernel?

    Maybe some sort of framework for allowing access to all devices from the network? That sounds like something hard that someone might want someday....

  • Shouldn't this be an "Ask SCO"?
  • DB Filesystem. If properly implemented, it can emulate a standard hierarchical filesystem for apps that need it. It would be just like an SQL query. "SELECT /usr/local/bin FROM hda LIKE redhat7.2" This would allow drag'n'drop [un]installation.
  • like in Partition Magic, but without the reboot.
    Would go nicely with the hot swoppable HDD and memory.

  • What about using MAS [] (Media Application Server) to provide network transparent sound? MAS already does this outside of the kernel and could be integrated into the kernel.
  • I'd like to see virutual terminals running different OSes. ALT-F1 (Linux), ALT-F2 (Windows 2000) ALT-F3 (Solaris x86) complete with a filesystem shim to allow them to share the same partitions, perhaps virtual NTFS via Linux but also map out protected areas to keep OSes from stepping on each other.
  • by goldspider ( 445116 ) <.ardrake79. .at.> on Friday October 10, 2003 @03:46PM (#7185444) Homepage
    The only barrier to me running Linux on my home computer is that Linux has no native support for serial-ATA hard drives. As such, of course, I am unable to install Linux.

    PLEASE include native support for SATA!!

  • I would like to be able to share proc, mem, disk, and net resources across multiple machines (as is partially implemented in openMosix []) AND run multiple instances of Linux on a single system (as in User-mode Linux []). These two features combined would provide the ultimate solution in hardware resource flexibility and scalability in large server deployments. It looks like VMware Server [] provides similar functionality, but with cross-platform capabilities and at a cost of over $1500 per processor.
  • One of the big problems with databases on Linux is that the system only does LRU replacement. This is horrid for databases that do sequential scans, because you are contunualyl replaceing what you just loaded a few megs ago. It is actually better to replace waht you just read, since you're done with it, and keep the other prior stuff in memory and then come back to it.

  • I see a lot of entries about application level stuff (yeh I got a list there too. :-) But laptops still have a lot of variables connected to the kernel:

    * APM / ACPI (still very hit & miss, and many vendors don't seem to follow the standard making it harder)
    * docking station support (sometimes works, sometimes it freezes hard)
    * hot swapping mice & keyboards (maybe 2.6 will make this better?)
    * Function (FN) keys don't work (you know, the vendor function keys that get you the keypad; this may be an X
  • How about a better /dev. Something that can handle dynamic devices. Something that only shows the devices attached to the system instead of 10,000+ . Something that actually works.
  • by GoNINzo ( 32266 ) <> on Friday October 10, 2003 @04:00PM (#7185567) Journal
    I wish there would be default stack protection, right out of the kernel. I'm tired of these repeated buffer overflows, and I know people can code right around them even with stack protection, but at least an attempt to make it harder for stack busting would be nice.
  • by temojen ( 678985 ) on Friday October 10, 2003 @04:08PM (#7185621) Journal

    When useing multiple USB keyboards all keyboards can be accessed through /dev/input/keyboard, and input from all keyboards appears on the console. (unless you don't insmod kbdev.o, and instead use /dev/input/eventx, which disables the console unless you also have a PS/2 keyboard, as well as useing a decidedly non-console like api)

    If instead there were /dev/input/keyboards optionally linked to the console, and /dev/input/keyboard0..n (like it is with USB mice), we could use multiple video cards and an appropriately modified X to build multi-seat workstations, POS terminals, etc without needing Xterminals.

    PCI VGA ~$50 vs ~$500 /XTerminal

  • by jd ( 1658 ) < minus city> on Friday October 10, 2003 @04:46PM (#7185782) Homepage Journal
    • SGI's Asynchronous I/O would be very useful
    • Lustre network FS seems mature enough to be a really good inclusion
    • Anything from SGI's ProPack that helps with scaling. If they can do 1024-processor boxes, then we aught to be able to, too!
    • One of the real-time patches (eg: RTAI) would be a cool addition, especially if it had no negative impact if not enabled.
    • I'd want to see the COMEDI patches for CAM devices, too. Hey, drivers are a Good Thing. Convince people Linux can handle the hardware, and you'll get their attention a lot quicker.
    • Devfs should NOT NOT NOT NOT be removed. It's a good concept, and that should be reason enough. If it's "abandonware", then threaten to bombard someone with the skills & time with SCO sourcecode until they submit and take it over.
    • USAGI's IPv6 should definitely be put in.
    • There are IGMPv3 patches out there, which really should be included.

  • Safe Video (Score:3, Informative)

    by cgreuter ( 82182 ) on Friday October 10, 2003 @05:43PM (#7186082)

    I'd really like to have an interface to the video system that is both fast and safe. At the moment, it's one or the other. Either I use straight X11 or I let the program bang on the hardware directly via DRI, SVGALib or the like.

    I'd like to see video drivers in the kernel. Not necessarily full-featured OpenGL drivers, but something that:

    1. Sets where in memory the card is allowed to read and write so that usermode programs can't trash system memory.
    2. Provides a reliable way to reset the video state so that we can easily get the display back to a sane state after something crashes.
    3. Provides fast, well-defined access to common (i.e. not cutting-edge) video functionality, possibly by letting the user program memory-map the frame buffer, so that simple graphics stuff is easy to do and doesn't need
    4. Provides a mechanism for applications to use the cards' advanced features (e.g. 3D hardware) so that binary-only device drivers are still possible, although not as part of the kernel. (This isn't strictly necessary from a technical point of view but I don't think most of the video card makers will release GPL'd drivers for their crown jewels. They might allow them for the basic stuff, though.)
    5. Associates video state with virtual consoles so that I can switch between graphical applications by hitting ALT+Fn. (Okay, this one isn't strictly necessary but it's really cool.)

    Of these, #4 may not be possible to do safely, or may only be possible for some cards. If so, it would still be a win because a lot of applications will do fine with only the basic functionality and over time, as the bleeding-edge stuff becomes mundane, it will slowly trickle into the #3 category.

Machines that have broken down will work perfectly when the repairman arrives.