Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

New Features For 2.5 Linux Kernel 141

Posted by michael from the modprobe-autopr0n dept.
An anonymous person writes "The current development version of the Linux kernel is 2.5. At the recent Linux kernel summit, it was agreed to have a "feature freeze" on this kernel by October 31, 2002. Here's a story looking at what's left to be merged before the freeze. Projects most likely to make it into 2.5 (and thus be a part of the next stable kernel, 2.6), include: the reverse mapping VM, the Linux Security Module framework, User Mode Linux and support for filesystems greater than 2TB."
This discussion has been archived. No new comments can be posted.

New Features For 2.5 Linux Kernel More

New Features For 2.5 Linux Kernel

Comments Filter:
  • Why's he "[A]n anonymous person" and not "an An Anonymous Coward"?

    Should I infer something about his identity from this? Should I infer that this means the /. editor knows this person's identity?

    Should I cue the X-Files theme song?
  • I think it's grand that we're already halfway, with this new milestone, to the 3.0 mark. It's great to see development moving along at such a good rate. Finally support for filesystems greater than 2TB, eh? Wow, now I can reduce my pr0n cluster to only 256 machines. Hehe. Keep it up guys.. keep up all the good work.

  • To infinity, and beyond! (Score:4, Interesting)

    by Dirtside ( 91468 ) on Saturday July 20, 2002 @02:29AM (#3921521) Journal
    So what I'm wondering is, wouldn't it be possible to invent a disk addressing scheme which basically self-extends, so that you would never really need to manually change things to support disk sizes beyond a certain size? In other words, depending on how big your hard drive is, the addressing method would change to address sectors of a certain size, keeping the need for indexes/tables/whatever down to a certain size, etc.?

    • Re:To infinity, and beyond! (Score:5, Insightful)

      by Christopher Thomas ( 11717 ) on Saturday July 20, 2002 @03:07AM (#3921567)
      So what I'm wondering is, wouldn't it be possible to invent a disk addressing scheme which basically self-extends, so that you would never really need to manually change things to support disk sizes beyond a certain size?

      Finishing moving disk-related parameters to 64 bits makes this largely unnecessary. It is extremely unlikely that we'll have to worry about devices with more than 2^63 blocks for a very long time (with 1k blocks, this would be eight [us] billion terabytes).

      Having the OS scale block size instead of just using a sane parameter width leads to much nastiness (remember how much fun FAT16 was).
      • Yeah, and 32-bit is more than we'll ever need. Who can imagine 4GB of memory in a machine! We'll never need more than 32-bit in our processors!

        or...

        640KB is enough for everyone!

        see a pattern already?

        dave

        • We may need it some day, but figure 64 gig (2^36) is a reasonable hard disk size today. Then assume that hard disk size doubles every year. We won't be running into the 64 bit limit for another (64-36=) 28 years!

          By that time all of our computers will be using 256 bit words, or maybe word-sizes won't really exist anymore. Who knows. Certainly Linux will have morphed into something entirely different. It's pointless trying to plan that far ahead.

          Also, there is in fact some limit to hard disk size, we just don't know what it will be yet. I have a 10gig drive in my laptop, and really I just fill it up with crap. I don't need half that much room. Until I start saving movies on my laptop I'll never need 80 gig. We'll run into physical limits too at some point.

      • disk-related parameters to 64 bits makes this largely unnecessary

        Right.
        2^63 blocks ought to be enough for anybody.

        Grin, duck & run

        -
        • Obviously, we might need more than 18,446,744,073,709,551,616 kbytes storage on a non-specialized computer some time in the future. Nobody, incuding original poster, deny that. But it would take a very long time. One thing is we don't need nearly that amount today, the other and perhaps more important thing is it is impossible now. Such storage with a reasonable physical device size would require either a very significant breakthru or several incremental, nevertheless revolutionary, refinements in storage technology.

          Harddisk storage space have grown roughly by a factor of ten million in the last 20 years. With the same rate, it would take another 25 years before we need that amount. I'm pretty sure kernel 4.0 will be out long before that.

      • Re:To infinity, and beyond! (Score:5, Insightful)

        by bruthasj ( 175228 ) <bruthasj@yaho o . c om> on Saturday July 20, 2002 @10:08AM (#3922424) Homepage Journal
        > for a very long time

        Let's compute this long time, just for fun. Let's see, we've got to assume a bunch of crap before we can compute a specific time for this. Using data from this [pro.on.ca] and this [pricewatch.com], let's assume that the current largest hard drive size on the market is 180GB with a doubling rate now at 9 months. (The 80s saw 30% growth annually, 60% in the 90s and 130% now.) Unlike processors, which have been steadily doubling every 18 months thanks to Mr. Moore, it appears that the growth rate itself for storage capacity is doubling every 10 years. Go figure.

        Let's use this, blow some hot air and molest these numbers a little bit.

        180 * 2 ^ p = 8 billion TB

        p = periods of doubling = 36

        Using a flat constant growth of 130% this would equal to

        36 * 9 = 324 months / 12 = 27 years

        Now, we see crossed 2 periods of doubling in growth, but can storage technology really experience growths of 260% or 520% annually. I'd have to say not, so I'll just give up computing the time given the growth of the growth right now. That's an assignment left to the reader -- I'd say it has to do with "e".

        Anyhow, the reality is:

        1) No one will ever read this comment since the article is so far down on the front page.
        2) We'll have quantum computers in 10 years that will use unlimited-bit numbers to access unlimited capacity storage devices.

        Ok, I'm all babbled out...
    • In other words, depending on how big your hard drive is, the addressing method would change to address sectors of a certain size, keeping the need for indexes/tables/whatever down to a certain size, etc.?

      I like this idea. Could be used for memory addressing as well, so you never run out of RAM.

      I see it working like this: use a 64-bit dword to store the address (or head/cylinder/sector/etc.). Only use 63 bits. When you run out of room, use the 64th bit to indicate that another 64-bit dword will be used along with the first (making it 126 bits of addressing, since the 64th bit of the second word would be used to denote a third 64-bit dword, which would give 192-3=189 bits, ad nauseum).

      We'd never run out of addresses, although there may be a performance hit once we start addressing really large amounts of data.

  • Serial ATA support - why? (Score:5, Interesting)

    by yem ( 170316 ) on Saturday July 20, 2002 @02:49AM (#3921545) Homepage

    From the TODO [lwn.net]:

    Would be nice to have before feature freeze, but most likely 2.7:
    ...
    o Serial ATA support

    From serialata.org [serialata.org]:

    Q13: When does Microsoft plan to support Serial ATA in its OS's?
    A13: Serial ATA is software compatible with Parallel ATA and requires no changes to Microsoft operating systems, or any other OS as well.

    If this is a drop in replacement for parallel ATA, why is support needed in the linux kernel?

    • Maybe they mean support for add-on PCI card SATA controllers, as opposed to controllers built onto the motherboard. Remember linux also needed special drivers for IDE controllers like the Promise Ultra66.
      • Obviously, one can't write a driver for a cipset if one doesn't have the chipset. Either the manufacturers will provide Linux drivers, or we will have to wait until someone skilled gets a card and writes drivers for it themselves.

        That's the inherent problem with add-on cards.

    • Because the hardware supports new features. You can use it in "dumb" mode, like you can run a 180gb Maxtor in PIO4 mode, but you're not getting your best use out of it (in this case, better speeds, cable detection, hotplug, etc).
  • Slocate indexes the contents of the disk. So does the MFT, FAT and whatever the Linux equivalent is called (I'm surprised I don't know this, but I don't).

    Would it be possible to organize that information in a manner so that it could be used to find / locat files in a very quick and efficent manner? I guess what I'm looking for is indexes which are updated on writes / unlinks. Would this be possible? Would there be drawbacks, and could they be counteracted? If someone with more skill than I implements this we'd all save a bit of time.
    • Both alocate and the FS table index the content of a disk but with different purposes _and_ structures.

      FS has a tree alike structure (which maps directly to the directories and files) to easily get from a file name to its position on the disk.

      [s]locate has progressive encoding (from their website http://www.geekreview.org/slocate/) which maps from name fragments to their complete name.

      Another difference is that slocate database structure is difficult to update, and you wouldn't want to do that everytime you rename/add/delete a file...

      Note that I'm not an expert, and this is just my (incomplete and perhaps even wrong) understanding .
      • Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...
        • Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...

          Heres a quick way to compare the functionality of the file system structures versus locates database.

          let's say we want to search for documents on the computer.

          File system :

          find / | grep ".doc"

          Locate database :

          locate ".doc"

          Compare the speed. Locate is incredibly quick, especially on large harddisks.

          Now compare creating a new file in the file system :

          echo "hello" > test

          to updating the locate database so that it can find the file quickly :

          updatedb

          (I think you need to be root to perform this).

          Here the filesystem wins easily.

          Unfortunately, like most computer algorithms, there is no "perfect" solution to searching for and adding files : if you optimise for searching speed, then update speed suffers. If you optimise for access and updating, then searching suffers. You can optimise for both (by having both the file system and locate), but you have gained better performance at the penalty of storing the information twice and hence taking up more space and greater code complexity - you need the file system code and locate, rather than just one or the other.

          Another way to look at it : why does your favourate computer textbook, or a world atlas contain an index? I mean, that's just duplication of information already on the map!

          Of course, it's because it's easier to find the place you are looking for in the index, but the map is actually useful for figuring out how to get there...
          • Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered. Obviously your comparison isn't very fair: you recreated the updatedb index from scratch, that would be unnecessary in the suggested system.
            • Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered.

              OK, you asked for it. I'll answer the question. Why is there not an implementation of locate (or slocate, which is much the same thing) which indexes filesystem changes in real time?

              Because of the kernel/user split. locate and slocate operate in user mode, getting information from the kernel in bulk, when updatedb is run. File creation / linking / unlinking / renaming happens in the kernel. There is no general interface for the kernel to alert userspace of changes to the filesystem - which means locate has no way of picking up updates short of rescanning the whole filesystem for them, manually. As you'll notice when you run updatedb, this is a laborious process, not suitable for running in real time. (Indeed, if you want real time, use find. locate was invented specifically for its cache - that's the only real advantage it has over find.)

              ...Which spawns two more questions. One, why can't someone add such a callback, and two, why not do a locate in kernel space?

              As to the callback, the concept exists in the form of directory notifications, where an application can request a list of directories its wants to be notified about. The kernel then makes it known when one of these changes in some way - link, unlink, rename. I know this has been implemented for Linux, but I don't believe it has made it into the mainstream kernels. It could be put to good use by a file manager application, or a "desktop icon manager" like the Windows Explorer shell.

              Having a similar callback for an entire filesystem - well, apparently nobody has found it necessary yet, and it would probably slow down a lot of filesystem workloads / benchmarks. Richard Gooch's devfs filesystem for device nodes does have this - it's called the devfsd protocol - but of course it's specific to the devfs partition.

              (Actually, I just remembered - as of 2.5.27 Linus is in the process of merging LSM. This is a security module framework which presumably would make it fairly easy to provide such filesystem-wide notifications to userspace. I don't yet know any more about it than that, at present.)

              So ... next question ... why not just do locate in kernel space? In short, too little benefit for too much complexity - i.e. it would be seen as bloat.

    • I thought that journalized file systems, ext3, JFS, Reiser, XFS, already did this. They are all, pretty much, linux standards, so to speak.

  • mounting floppies, CD's and DVD's (Score:5, Interesting)

    by oever ( 233119 ) on Saturday July 20, 2002 @03:01AM (#3921562) Homepage
    I'd like to install linux on my Mom's new computer, but the mounting of disks should be a lot easier. All we regular linux users are very accustomed to it, but really, it's rediculous.

    It possible to jerk out my netword PC-Card. The network is closed down nicely. Reinsert the card and the network restarts.

    But if I put a floppy in the drive, I cannot read it by default. Aargh. Sure, I can use automount, but then it's not safe to just remove the floppy.

    And for the CD it's even more weird. A CD/DVD player has a button. This is disabled when I mount a CD. So a mounted CD cannot be ejected. Yet, mounting the CD when it is inserted. That's apparently asking too much.

    It's great that so many new features go into the kernel. But why can't a simple feature like this make it into the kernel. There's no lack of patches.

    • Re:mounting floppies, CD's and DVD's (Score:4, Insightful)

      by yobbo ( 324595 ) on Saturday July 20, 2002 @03:08AM (#3921568)
      supermount is entirely adequate, IMO. Sure there may be dangers removing floppies, but then again, do we *really* need floppies still? I thought we were over the days where we'd save our documents to 8 different disks and hope one of them worked when we got to work...
      • I keep trying to take the damn floppy drive out of the various systems I deal with, and I keep having some rediculous reason where I *need* to put the horror back in. It's bizzare. Try it: take a machine that hasn't had a floppy inserted into it in years. Remove the drive. It is a physical LAW that the machine will require the use of a floppy drive within three days.

        And my goodness: is there any brand of floppies left that doesn't have at least three dead in a box of 10?
        • is there any brand of floppies left that doesn't have at least three dead in a box of 10?

          No, there bloody isn't. I now maintain a small collection of antique floppy disks for the rare occasions where I want them to work.

          Dave
        • I've been running my machine without a floppy for months now. Then again, it never had a floppy to begin with, so maybe the "law" should be extended to include only machines that had a floppy in the first place.
          • I also made this leap when I purchased my machine this spring. No floppy for me. The only reason that I would ever miss it, is a nice 3-floppy networked debian install. I decided to suck it up and forego that niceness.

            My main reason for the decision though is that while in school I worked at the University Help Desk. You have _no_ idea how depressing it is to watch people lose their thesis because the only place they saved it was on a floppy! Sure, they should have backed it up on the network (that's what it's there for)...anyway, floppies just aren't reliable for anything anymore.

            It's time to start the push for elmination of this antique and very fragile technology.

            Down with floppy drives and disks!

            -Ben
            • I agree, I'd like to see them go, but you've got to tell the motherboard makers to give us another route to flash our BIOSes. Especially for those of us who do not run any sort of MS Windows. I still have to keep a win98 boot floppy around just for this purpose.
              • It would actually be quite simple for them to do:

                There's some free DOS clone out there, I can't remember the name, but it works as well as, or better than DOS6.

                So the mfr could just put those files need to boot a disk from that DOSclone, as well as the files needed to flash the bios, in a compressed archive. Then all you have to do is uncompress the archive and burn in on a cdr -- and then boot the CD.

                --
                Posted from Gentoo+KDE3, day1. GENTOO ROCKS!!! You won't understand 'till you try it. Don't be intimidated, it's not hard to install! It's so freaking fast!
      • It's not really a floppy issue; it's a removable writable media problem. There's Zip disks, etc. too to think about. (Yes, I still use Zip disks.)

        The problem has kind of been sidestepped by the popularity of CDR (and RW, and DVD, etc) drives which typically end up completely copping out by requiring a special application to write, instead of just being a filesystem. That really sucks, BTW, and it's even worse.

    • You probably want supermount. Just ask google.

      Here's a patch for 2.4.18:
      http://espectro.hypermart.net/supermount. patch

      The latest version of Mandrake Linux includes supermount and I've grown to like it. It would be nice to have it in the kernel, even if it was marked EXPERIMENTAL.
      • Its marked experimental because it has race conditions. Heres a quote from this LWN article [lwn.net]:
        The most common answer to this problem seems to be supermount... There is also evidently a need for an audit by a serious filesystem hacker to deal with some questionable practices and race conditions.
        You can find more referencing to the race conditions in Supermount here [google.com].

    • Re:mounting floppies, CD's and DVD's (Score:4, Insightful)

      by rossz ( 67331 ) <[ogre] [at] [geekbiker.net]> on Saturday July 20, 2002 @03:14AM (#3921582) Journal
      The need to mount and unmount CD/DVDs has been one of my pet peeves. Hell, Windoze can detect when a new disk is inserted and even launch stuff (which is annoying but can be disabled). So use the same technique and automount the damn thing. And when the eject button is pressed, catch that and umount. If the Microsoft programmers can do it, it can't be all that hard!
    • For the floppies just use mtools. It is much simpler and provides all the commands that you would expect. Also has the advantage (?) that it is similar to windows commands. No need to mount/umount.

      As for CDs, put the CD in eject -t and then mount /mnt/cdrom followed by eject which will autmatically umount it. I think you don't even need the initial eject -t command.

      Just my $0.02

    • Re:mounting floppies, CD's and DVD's (Score:5, Informative)

      by DGolden ( 17848 ) on Saturday July 20, 2002 @03:52PM (#3923865) Homepage Journal
      I find a deeper problem with removable disks on Linux and Windows: ranted about this at length on LKML a while back. I'm now trying to do something (possibly misguided) about it. The basic problem is that a disk is not the drive it is in.

      both Unix and Windows, in general, assume it is. You don't copy a file to "disk xyzzy", you copy it to "A:" or "the filesystem mounted on /dev/fd0" - /dev/fd0 identifies a drive, not a disk!

      The amiga got this right:
      a disk became part of the filesystem based on its label/id, if possible -
      so I could say "copy mfile.doc to xyzzy:mydocs", and if the disk xyzzy was unvailable, the system would prompt for it, while the copy process blocked waiting for it. If I put it back in a different drive, the system didn't care.

      I'm currently casting an eye over the linux block device and filesystem code with a view to mangling into something vaguely amiga-like - but I'm not really even a C programmer (more of a Lisp guy), so I make take a while.

      Basically, a disk contains a set of blocks. Some or all of those blocks may be accesible via a block device file. But you should be able to mount the filesystem "on the set of blocks of the disk", not the set of blocks currently accessible by a particular drive - disk partitioning schemes still have one or two fields to facilitate this, the disk label/name and/or a uniqueid.

      If I have a disk labelled "peaches", I want it part of the filesystem at e.g. /mnt/peaches, and if I have two drives, I don't want to have to care about what drive it is in!

      • This isn't a full solution, but some "mount by label" stuff is already there.

        e2label /dev/foo "Foo"
        mount LABEL=Foo /mnt/foo

        Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.

        If you actually want to hack this, look into the executable maps and wildcards features of autofs (man 5 autofs). It might be possible now with some clever automounter config files...

        • Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.

          The Linux mount program knows about SGI XFS labels. I'm pretty sure it doesn't parse labels for FAT, HPFS or NTFS (yes they all have them) or whatever other filesystems have labels - probably because nobody really needs to specify label-based FAT mounts in fstab (it's a legacy format anyway). Plus, FAT/HPFS/NTFS labels are much harder to extract than ext2/ext3 and XFS labels, which are in fixed fields in a fixed superblock. (In FAT, the label is a pseudo-file in the root directory.)

    • Swapping floppies in Windows has desasterous effects on the data on both media, if there are any documents open.

      I've seen years of work being destroyed, working at the university's help desk, because our users were able to do this. It shows the cynical side of Windows' user-friendliness.

      But I admit, I had to learn to appreciated mount myself. Joke opportunities helped a lot though :)

    • I just instructed my parents to mount and umount usnig the icons on KDEs desktop. Told them it is more secure and lessens the risk of data corruption. They are perfectly happy about it, it took them less than 5 minutes to master. Just go ahead and teach her.
    • oever says:
      Sure, I can use automount, but then its not safe to just remove the floppy.

      $ more /etc/auto.master
      # Format of this file:
      # mountpoint map options
      # For details of the format look at autofs(8).
      /misc /etc/auto.misc --timeout=1

      A 1 second delay good enough? There are still some details about remembering to change out of any automounted subdirectories, but this setup "Works For Me(TM)"

      I also use the CD like this, and have setup some view profiles for Konqi that start in the directory. Now I can buttons on the desktop I click to look at the cd... and no need to care about mounting/unmounting it.

  • I see.. (Score:1, Troll)

    by MOMOCROME ( 207697 )
    Doesn't this bode ill for the kernel dev efforts, if the concept of "feature freeze" must be reported on and placed in quotes as if it were some novel new design technique?

    This should be standard practice. Sure reporting on the features to be included before the freeze is worthwhile, I can see why that's interesting, but "feature freeze" in quotes? C'mon already. every two-bit dev team from Seattle to Sri Lanka must reach a point of "feature freeze" during a dev cycle.

    • No, you got it wrong. It's not a new concept, they put it in quotes, because basically those are gonna be the features which they work the bugs out of first. Everything else is probably gonna have a big "EXPERIMENTAL" tag on it when go to configure your kernal. Then once they get 2.6 stable, they move onto 2.7 and work more seriously on the stuff that didn't get that much attention in 2.5. Gosh I hope I haven't mangled this process too badly.

      • Re:I see.. (Score:2, Insightful)

        by MOMOCROME ( 207697 )
        I think you might have it wrong...

        If what you were saying was the case, the writeup might appear more along the lines of ' ..feature freeze for the "2.5 kernel"...' instead of ' ..."feature freeze" for the 2.5 kernel...'.

        If you see what I am saying. The emphasis established by putting the phrase "feature freeze" in quotes is suggestive of that particular practice being unusual.
        • If you see what I am saying. The emphasis established by putting the phrase "feature freeze" in quotes is suggestive of that particular practice being unusual.

          Which, historically, has been the case. Linus admits he isn't very good about things like that ... anyone else remember the "Give Linus a Backbone" website shortly before the release of 2.4?

          In any event, it is really unconscionable that XFS isn't being integrated into 2.5. It is hands down the best, most reliable filesystem under Linux bar none, and the only filesystem I will use on mission critical servers running Linux.

          This politicking about kernel patch sizes and "I don't like the way you tweaked [whatever]" has really gotten out of hand, and the result is that we have subpar filesystems integrated into the default kernel while the best of the breed remains an external patch.

          Maybe we'll get lucky and Linus will cave once again and let XFS through, but my money is on something a lot less innocuous, like another VM revamp in the middle of a "stable" series a la 2.4.
          • In any event, it is really unconscionable that XFS isn't being integrated into 2.5.

            It is nothing of the sort. For one thing, you should look up the word unconscionable [m-w.com] - "I do not think it means what you think it means." For another, if you think it such a great crime, why don't you undertake to integrate it?

            Hint: "integrate" does not mean "take the SGI patch and throw it at Linus". It means "comb through SGI's patch, figure out what all was added to the kernel to support XFS, and take it apart feature by feature." Then, for each separate feature:

            • Produce an independent patch - independent meaning does not require the rest of the XFS patch, does not break the kernel, and actually accomplishes something on its own.
            • Figure out how to justify its existence in a sufficiently convincing way that Linus knows you're actually trying to improve the kernel, not just throw crap in it so you can have XFS.
            • If Linus thinks your feature is stupid, poorly designed or poorly implemented, he's probably right. He's pretty amazing that way. You must take his criticism into account to figure out another way to get the needed facility. (If necessary, hash something out on linux-kernel or linux-fsdevel.) Iterate until you get a patch Linus likes, then adapt XFS to use that instead.

            Finally, when Linus has merged enough of your patches that XFS has all it needs, send Linus the XFS filesystem code itself. At this point Linus will most likely take it. If Linus has objections to the XFS code itself, work with him to clean it up as necessary. Remember, just because code was good enough for IRIX doesn't mean it's good enough for Linux. (:

            Here endeth the XFS Integration Mini-HOWTO.

            What? You don't want to be the one who gets to do all that after all? Then quitcher bellyachin'.

    • are you new here? (Score:4, Funny)

      by Xtifr ( 1323 ) on Saturday July 20, 2002 @04:05AM (#3921659) Homepage
      The kernel developers know what a feature freeze is. There's no quotation marks around it in the referenced article. The quotation marks in the slashdot headline came from an "anonymous person" somewhere, and the slashdot "editors" decided to leave it there because they are "editors", not editors.

      #include <usual lecture about reading the article before commenting.h>

  • Left Out and Left Behind (Score:3, Informative)

    by tarsi210 ( 70325 ) <nathan@@@nathanpralle...com> on Saturday July 20, 2002 @03:11AM (#3921571) Homepage Journal
    Now, someone correct me, but it sounds like a lot of really really necessary crap is (probably) going to be left out of the 2.5 kernel (which will become 2.6 stable eventually). I'd like to mention a few here and why I'm stunned that they probably won't make it.
    • Add XFS (A journaling filesystem from SGI) - Excuse-the-hell me? Isn't the idea to get journaling filesystems in to the kernel because that's what everyone wants? XFS is proven, get it the heck in there.
    • Asynchronous IO (aio) support - This is really surprising in some ways. IIRC from the kernel summit summary, this was a hot topic and argued vehemently. Even Linus agreed it was a Good Thing(tm) and should be done. If I also remember correctly, it's a hell of a lot of work, so I can justify that.
    • Full compliance with IPv6 - Ok, for crying in my lukewarm beer, this needs to get in there, folks. IPv6 needs to get going and you're not helping.
    • ext2/ext3 large directory support: HTree index - Sounds like something that enterprise Linux people would enjoy, yes?
    • Remove the 2TB block device limit - Ditto.
    • Overhaul PCMCIA support - Ogg heat metal. Ogg form new stick from copper, copper much better than wood stick. Ogg progresses. Anyone else think that PCMCIA sucks under Linux? It could use an overhaul in a large, hairy, neanderthal way.
    • Reiserfs v4 - See the comment above about XFS.
    • Serial ATA support - I don't know how close this standard is to manufacturing, but it certainly sounds like this is the way that hardware is going (and bless them, too.) Probably a good thing to NOT leave in the dust.
    That about does it for the ones that make me cringe uncomfortably. Past that, I can rationalize the other ones out. These just flick that, "Whoa, aren't you making a mistake?" light inside my head.

    And would anyone care to comment on the SCSI interface? According to the kernel summit, there was going to be much code yoinkage and redoing for the entire subsystem. Where does that play in the 2.5 freeze?
    • * Add XFS (A journaling filesystem from SGI) - Excuse-the-hell me? Isn't the idea to get journaling filesystems in to the kernel because that's what everyone wants? XFS is proven, get it the heck in there.

      Easy there - XFS has been available available for months for those that really want it. It'd be nice to have it in the base kernel, but its not like you're going without.

      I'd like to know exactly what hasn't been implemented in IPv6...

    • Re:Left Out and Left Behind (Score:1, Insightful)

      by Anonymous Coward
      Yes. Serial ATA is going to be BIG once it gets to the marketplace later this year. I have a feeling we'll see it added to 2.5 pretty quickly after release.

    • Full compliance with IPv6

      Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

      • OK, so I jumped the gun a bit there - there are bits still missing from the Linux IPv6 stack which make it non-compliant, such as IPSec and such. See the USAGI project [linux-ipv6.org]. But the major points of IPv6 certainly work on Linux.
      • Full compliance with IPv6

        Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

        Here's a little info [tldp.org]. Doesn't go into specifics. Follow the links and you end up here [linux-ipv6.org].

        They key is the "my home network" part. The router for an autonomous system would probably require full support. I'm running RH7.3 (kernel v2.4.18) and i don't see kame [kame.net] dancing.

        • Hrm I can see the dancing kame on the debian box which is doing the actual routing (or rather, I can't because I'm using lynx, but I'm seeing the IPv6 page :)). I can't on this box because neither IE6 nor Mozilla 1.1 appear to have IPv6 functionality on Windows. However the debian box, having been allocated a /64 by FreeNet6, assigns addresses on to the ipv6-enabled (windows) computers on the LAN, and I can ping6 www.6bone.net from my Windows box.

          Still, Microsoft still hasn't got a production driver out for Windows either, so Linux isn't behind yet :) (although they're apparently going to release a production driver for .NET server).
    • Personally, I'd love to see NTFS write support "finished" (i.e. made stable), but judging from the state of things, that's a high priority for few...

      Chris

    • Depends on how you look at it. If the feature freeze holds (a big 'if') then 2.7/2.8 will follow in reasonable time. There's always a next version.

      The danger is that the feature freeze holds just well enough to keep a few important features out, but not well enough to bring a stable 2.6 quickly. That's pretty much the worst of both worlds.

      I'm hopeful anyway. I think everybody is serious about getting the release cycle shorter.

      • Oh, I agree with the shortening of the release cycle. My only point that I was trying to drive (and heck, it was late, maybe I wasn't clear enough) was that in software development, you have to balance the need to get the product out with the need to get the important features in. Although Linux isn't being "sold" to anyone, in a sense it is...to maintain corporate support and usage of Linux, the kernel has to maintain a software product's appeal, despite its free nature.

        To this end, I put on my corporate CTO's hat and looked at the listing of things being left out and said, "Uh...maybe a tad longer development cycle rather than shorter and getting a few more of the features in would be a good thing for the market."

        Mind you, I'm not a kernel hacker and therefore some of these issues I may have said, "Ok, why aren't these in?" and the reason is because they're involved beyond what I know.
    • # Reiserfs v4

      Will not be ready/tested. You can always patch your kernel to add support for it. It just won't come default as they can't bundle everything, specially the non stable developements (reiser4 has not even been released yet).

      # Full compliance with IPv6

      I am not an expect, but surelly the "full compliance" means a lot of unused parts that are non-critical and non-important and can be implemented later. For example, no C++ compiler implements all the C++ specs. Does this mean C++ is unsopported?

      # Serial ATA support

      What's this for?

      # Overhaul PCMCIA support

      I agree, it sucks a bit. I'd like it to be more userfriendly. I sometimes don't know what is used for what (what do you have to check to get ATA CompactFlash cards to mount?). Probably just my fault here! (the PCMCIA network card works great though, and Slackware 8 default kernel autodetected it).

      • Re:Serial ATA support (Score:1, Interesting)

        by Anonymous Coward
        Why is Serial ATA support important?

        Because it is fast looking like serial ata disks are going to be hitting the market in a big way, before the end of this year. By the time 2.6 comes out, it is going to be more than important.

        Controllers from all the major manufacturors are out as of now, and disks from seagate and maxtor are likely to be out next month.

        And to boot, all of the prototype Opteron motherboards seen to date have had Serial ATA onboard. It seems improbable that they'll have a standard ide controller as well, considering that the serial ata controllers can be used with standard ata drives, via a converter.

        If support doesn't appear, linux users will be left in the dust.
    • >* Add XFS (A journaling filesystem from SGI) - >Excuse-the-hell me? Isn't the idea to get journaling >filesystems in to the kernel because that's what everyone >wants? XFS is proven, get it the heck in there. I agree that XFS had been proven stable. Right now it is been merged in a seperate cvs repos (SGI). I tried to run 2.5.15, I think it was, with XFS cvs. It didn't go very well, when I did large transfers, the system would completely lock for about 5 sec. and then continue. This happened every 5 minutes or so. That combined with the fact that the ide had been rewritten and isn't really stable has given me some series doubts about trying 2.5 again. About ReiserFS v.4 is it _not_ going it! There isn't even a downloadable version out yet. Is way to alpha/beta to go into 2.5.
    • # Reiserfs v4 - See the comment above about XFS.

      ReiserFS v4 makes some BIG changes to the kernel - for instance, it requires that files can be also directories at the same time. It's currently slated for December 31st, so I doubt it'll be in the next kernel. It's a big bit of work. Anyway, I think most distros have had ReiserFS v3 (which is also journalled) in their for ages, I know SuSE has, or you can recompile your own. Having it in the base kernel is nice, but hardly necessary.

    • Serial ATA is software compatable with paralell ATA, so I hardly see a need to "add" support for it.

      If you mean Serial ATA add-on cards, well, people would have to have them and write drivers for them, or the manufacturers would have to write drivers. It's hardly reasonable to expect drivers that don't exist to be included in the kernel.

  • OK, I know, I'm stupid when it comes to knowing anything about the Linux kernel, so please be patient.

    I just got a new computer, and I installed a dual boot of Windows 2000 and Redhat 7.3. When I went into Linux, and tried to mount windows (mount /dev/hda1 /mnt/windows) an error was returned saying that the kernel did not support NTFS. Windows 2000 uses the NT file structure as oppoesed to FAT32 that previous versions of windows have used. My question is whether or not newer versions of the kernel will have the ability to mount windows 2000 partitions.
    • They have been able to for ages. Looks like the default RH kernel isn't built with this enabled.
      • Looks like the default RH kernel isn't built with this enabled.

        They don't have anything on their kernel which is marked experimental/dangerous in the config. Of course, write support is really dangerous. FWIW, they don't have UDF support either.
        • I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?

          • I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?

            Well, if the code is not reliable, all bets are off when it is mounted, although in the config it says that read support is just experimental and not dangerous. I don't think RedHat would want to take that chance.

    • There has been some support for for the NTFS filesystem available for years. The original driver system is no longer developed, and a new system is being actively developed (link [sourceforge.net]). Unfortunately, because of the complexity of this filesystem, which is not fully documented by Microsoft, only read support is satisfactory - i.e. it may be dangerous to write to an NTFS filesystem from Linux.

      You may wish to explore loading NTFS as a module or compiling it into your kernel.

    • Re:Support for mounting NTFS (Score:4, Informative)

      by Zapdos ( 70654 ) on Saturday July 20, 2002 @09:30AM (#3922252)
      3.2 How do I get Linux to understand NTFS?
      There are two ways to get NTFS support. The simplest is to add the NTFS module to the kernel (as root):

      modprobe ntfs

      If this fails, modprobe: Can't locate module ntfs, then your distribution didn't install the NTFS module.

      The second way is to recompile the kernel, yourself. This sounds like a lot of work, but it isn't that hard. Have a look at the section: How do I add NTFS support to Linux?

      3.3 Can I write to an NTFS Volume, too?
      NO.

      There are two drivers, currently. The original driver, in 2.4 has some write code in it, but it is extremely dangerous to use it. The possibility of destroying your filesystem is very high.

      The new driver, introduced in 2.5.11, has no write code at all. This may sound like a backwards step, but it was necessary to rewrite the driver in order to make the future coding simpler and more solid.

      Adding write support will take a long time. NTFS is built like a database. Any changes you make, necessitate making changes in many places, for consistancy. Make a mistake and the filesystem will be damaged, make too many mistakes and the filesystem will be destroyed. Also, the current developers are only working on NTFS as a hobby, during their free time. If you'd like to help, please email: webmaster@flatcap.org.

    • Since Kernel 2.2 I think NTFS paritions have been supported as read-only.
      The stock kernel from your distro probably doesn't have the support comiled in. Assuming the kernel was compiled for loadable modules, you could compile the code as a module, and it would probably auto-insert itself when you tried to mount the partition.

      The HOW of getting that done isn't very difficult, but beyond the scope of this thread.

  • My project (Score:5, Funny)

    by Alsee ( 515537 ) on Saturday July 20, 2002 @03:44AM (#3921629) Homepage
    support for filesystems greater than 2TB

    Ah, good! This has been a major stumbling block for me. I've been writing a guide and I hit the 2TB ceiling. My target market is hitchhikers.

    -

  • kbuild? (Score:4, Interesting)

    by spongman ( 182339 ) on Saturday July 20, 2002 @04:50AM (#3921717)
    how about kbuild that has been ready for a fucking eon? yeah, yeah, it's a big patch, so were the first few that went into 2.5, and kbuild2.5 was ready then, too. and still we wait for kai to pretent he's helping...

    politics: from the greek: poly:(adj.) many, ticks:(n., pl.) blood sucking animals.

  • v4l2 [thedirks.org]

    This would allow the latest bttv [bytesex.org] driver to be packaged with the kernel once more...

    After the preemptive patch, that's the first patch I run on a plain vanilla kernel.

  • In kernel checkpoint support? (Score:3, Interesting)

    by maynard ( 3337 ) on Saturday July 20, 2002 @07:24AM (#3921926) Journal
    I'd really like to see one of the checkpoint patches includeded in the mainline kernel series. There are several to choose from: EPCKPT [rutgers.edu], CRAK [columbia.edu], CP [nersc.gov].... Which one doesn't matter (feature wise), they all basically allow for the kernel to stop a process, save it's state and pages to a file, and then load and restart that process by request.

    Yes, I could distribute a patched kernel across all of my systems. But then I'm tied to that kernel until whichever project I'm following updates their patch (or I update it myself, and I don't consider myself competent as a kernel hacker). This would be a really useful mainline feature for those of us in the scientific computing community. Wasn't there some talk of one of these going in 2.6 proper? --M

  • So much for Enterprise Linux (Score:3, Interesting)

    by baptiste ( 256004 ) <mike&baptiste,us> on Saturday July 20, 2002 @08:02AM (#3921995) Homepage Journal
    While I understand that you have to draw the line somewhere and that it can be difficult to deal with such far flung development groups with their own priorities. BUT...

    Why is XFS still not considered ready? Its in almost every major distro except for RedHat. Heck - the XFS team even provides custom XFS RedHat installer iso's to fill in the gap. XFS v1.1 is already released and is being used on huge fileservers in production all the time. Why can't we get past the 'we don't like the way you tweaked module X' and finally move forward.

    I wish EVMS was going to be ready - this is going to be huge for enterprises - finally a unified, feature rich storage manager.

    LVM 2.0 - well, I'd rather ensure 1.x is super stable (it is so far for me) so this isn't as big a deal.

    Serial ATA - Bummer. I realize this is new. But I get the feeling Serial ATA is going to be huge, especially for lower end servers. Finally getting real hot plug support and a setup that'll make things easier on the HW RAID vendors (I can't wait to see a Serial ATA card from 3-Ware!) I would hope this would be flagged as something to be merged into 2.6 as soon as its possible, even if marked experimental.

    Don't get me wrong - I'm really psyched for 2.6, but there are some features (whose development is out of the control of the core kernel team) we really need, to push Linux farther and farther into the enterprise. I know you can patch in what you want - but many IT folks, even Linux zealots, are wary of doing so in production - they want stock RedHat kernels so they can tell their boss its gone through RedHat Q&A and all that. Its CYA sure, but necessary in many environments. Granted RedHat often adds stuff not in the stock kernel, but not usually hueg features.

  • LSM to be included - yay! (Score:3, Insightful)

    by sasha328 ( 203458 ) on Saturday July 20, 2002 @08:38AM (#3922097) Homepage
    I think it is about time that the LSM (or anything similar) was included in the kernel. When it comes to access control, I think Windows NT/2000 wins hands down against Linux.
    I know I am running the risk of being modded down for saying that Win2K is way ahead of linux (or other *nix for all I know) but in the real world of file sharing, we use permissions and auditing quite a lot; these are not always black and white (what linux is currently capable of) permissions, they are often varying shades of grey.
    Hopefully, with LSM, this will change even if it is in the future (1 year? 2 years?)
    For a good explanation of the LSM, read this from NSA/SELinux [nsa.gov]
    • well, if you are refering to ACLs in the filesystem, Extended Attributes has been in the VFS since 2.5.3 so now it's just up to the filesystems to include ACL information and the NFS server/clients to support the ACCESS command(there's a patch floating around to do it, but I haven't heard anyone talk about). Samba already supports ACLs if you are running XFS or Ext3+acl. If I can get filesystem/nfs-supported ACLs, i'll be happy.
      -Aaron
    • I think it is about time that the LSM (or anything similar) was included in the kernel. When it comes to access control, I think Windows NT/2000 wins hands down against Linux.

      Well, Linus has started integrating it, so you'll get your wish.

      As to whether NT is superior, it depends on if you measure by flexibility or by ease-of-use. NT ACLs are hella flexible - you can grant or deny a whole range of permissions to anyone you wish. The Unix "read write execute / owner group other" seems horribly primitive by comparison. But it comes at a cost. NT does not come with any sane way to manage permissions. The GUI tool? Puh-leeze. It can't even add / remove users from a tree of files without resetting every file in the tree to the same ACL. It doesn't give access to the "deny" half of an ACL either - everything is "start from zero, and allow". It doesn't seem to have any "summary mode" or search capabilities - you have to click on objects individually to find out their status, which gets pretty old on even a small filesystem.

      The command line CACLS.EXE is not much better. It is some better, but still does not have a "search" mode, or an easily greppable output format - there seems to be no equivalent to "find -user" or "find -perm".

      Finally, although the order of ACL entries is significant in NT, the tools (both GUI and CACLS.EXE) do not seem to provide access to the ordering. (CACLS lets you view the order, but not change it; the GUI goes so far as to sort the entries alphabetically! - misleading at best.) This is a fatal flaw, and shows that either the tools are inadequate, or the system is overdesigned. (IMHO, both.)

      Windows 2000 is a bit better - the GUI at least gives you access to the "deny" half of things, and exposes the "inherit permissions" functionality which can simplify life considerably.

      Unix / Linux, on the other hand, may not have ACLs, but frankly, with a few well-chosen groups you usually don't need ACLs anyway. (My evidence: AIX and IRIX do have ACLs, yet in several years of AIX/IRIX administraction, I've never actually used them, or wanted to.) And, thanks to both the simplicity of the scheme and the maturity of the tools, Unix permissions are much easier to manage than NT ACLs, in my experience. (Speaking of which, I may as well admit some serious bias, since I've had a lot more experience managing Unix than NT.)

  • What are the most exciting things currently being worked on for Linux?

Slashdot Top Deals

Whatever is not nailed down is mine. Whatever I can pry up is not nailed down. -- Collis P. Huntingdon, railroad tycoon

Close