Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

What Happens To -AC (And Other) Kernel Mods? 164

Posted by timothy from the cyfrifiadurol dept.
RedLeg wrote with this poser: "So, looking at the changelog for the 2.4.9 kernel release, I see a few '- Alan Cox: driver merges' entries. Intelligent consumers of (or those of us who modify them for our own uses) RedHat Kernel src.RPMs look at the patches in the RH kernel builds. Alan's (and other persistent RH) patches don't seem to be integrated into Linus' 'mainstream' kernel trees on any kind of a predictable basis, and this frequently causes projects like freeswan to have difficulty merging their patches (not intended for kernel inclusion) with kernels that appear 'in the wild' like the kernel RPMs from RedHat. Often, kernel patches for obviously older kernel versions continue to be applied (in the RPMs) to newer kernel versions. Alan is a RedHat-er, so he obviously has an inside track to RedHat kernel builds, but he's also Linus' Right-Hand man, but his patches are not (apparently) consistently making it into the 'mainstream' kernel. What am I missing?" Who better to answer this question than Alan Cox? Alan was kind enough to write an explanation of the (still complicated) process of merging -- and it's not as simple as who works for what distro maker ;)

Note: Here's what Alan passed on in response to this question. As usual, things aren't quite as simple as they first appear. -T.

Alan Cox: Probably the first thing to explain is the Red Hat kernel. That actually isn't something I am responsible for. Arjan van de Ven is the keeper of the distribution kernel, and has the unenviable task of getting a kernel together that will actually pass all the brutal QA testing. Arjan is perfectly entitled to (and sometimes does) throw out bits of -ac changes.

You'll see Red Hat patches being merged into -ac and Linus trees when appropriate, often from Arjan or Pete Zaitcev. Many of the other patches in the RH tree are considered "fixups" - they are workarounds for problems but not generalised or clean enough to feed into the main tree without further work. Others are RH specific patches for things like packaging.

With the -ac tree I try and do rapid rolling releases, sucking in new code to test it and also its interactions with other new code. By doing releases every few days I get a high number of people testing and reporting bugs before there are too many possible causes. This is how Linus trees used to work long ago, and I still think its the better technique.

At regular intervals I take stuff from the -ac tree and feed it to Linus. Sometimes Linus doesn't want to take other changes in case they confuse other things being done, sometimes they just vanish and fairly often they get applied.

I'm actually limited in the rate I can forward patches because I need to feed Linus blocks that are debuggable. Thus I don't want to feed Linus both file system and disk driver changes at once or I won't know which to blame if there are corruption reports.

I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so. Thus the USB diverges quite a lot because Johannes Erdfelt has chosen not to feed chunks of the USB and input changes on. Similarly, the user-mode-linux port in -ac has not been fed on to Linus because Jeff Dike wishes to improve it further before submitting it.

I have been concentrating on getting the driver code and some architectures synchronized with Linus, and that is now mostly done. The next big challenge is getting all the file system work on to Linus, and Al Viro has begun that and fed Linus the first blocks of the superblock handling cleanup.

Finally we have changes that are down to fundamental disagreements, perhaps in part stemming from the fact my background is real production systems rather than OS design work. Linus decided to update the 3D support without keeping back compatibility - I kept both. Linus I suspect will never accept a patch to do that. Secondly he decided that he didn't wish to allocate new device major numbers but look for a saner solution over time. Laudible, but not in the middle of a stable release. The -ac tree has drivers allocated "non-Linus" major numbers that are recognized by LANANA and thus common across vendors. These drivers like the HPT370 and Promise IDE raid will thus always be part of the -ac tree only.

The -ac tree also tries hard to avoid any incompatibilities. Having applications that require -ac or Linus trees is simply not an acceptable situation. The only specific exception for that right now for 2.4.x is deep at the system level and is for quota tools. That one was unavoidable to get 32bit uid quota working.
This discussion has been archived. No new comments can be posted.

What Happens To -AC (And Other) Kernel Mods? More

What Happens To -AC (And Other) Kernel Mods?

Comments Filter:

  • Post-Mortem debugging of multithreaded processes (Score:5, Interesting)

    by sllort ( 442574 ) on Wednesday August 22, 2001 @12:06PM (#2204619) Homepage Journal
    One thing that's been in the -ac kernels for quite some time is the ability to post-mortem debug multithreaded processes. That is, under the production kernel, when you core dump, all the threading information is lost. You can't get the call stack of each thread. With the -ac kernels you got one core file per pid, with each LWP (lightweight process) getting its' own core file.

    Considering that Solaris has had this (what seems to be BASIC) functionality for years, why do we see the continued insistence on keeping this functionality out of the production kernel? Are we waiting for the gdb team to catch up?

    Until this is fixed, multithreaded programming under Linux will remain a black art - only developers willing to apply hordes of -ac patches to a homegrown development kernel have a change of successfully developing a multi-threaded application under Linux. Considering that many commercial software development packages (RogueWave, for instance) won't even support you if you're not using a RedHat released kernel, this puts multi-threaded development "out-of-bounds" for many.

    Merge the -ac kernel mods!
    • Max OS X has this feature as well. If you set CRASHDEBUG=-YES- in /etc/hostconfig, you will get a dump of all thread stacks and the CPU(s) registers when a process bombs out. Very handy. I believe that HP-UX also has this feature. Surprising that Linux doesn't.

    • Re:Post-Mortem debugging of multithreaded processe (Score:5, Informative)

      by n0ano ( 148272 ) <n0ano@arrl.net> on Wednesday August 22, 2001 @02:53PM (#2205147) Homepage
      The thread core dump patch was originally put into Alan's tree around the 2.4.3 time frame. It was quite correctly labeled experimental at the time (it took a few iterations to get it right.) The intent is to merge it into Linus' tree at some time, it just hasn't gotten there yet.


      In the mean time, if you're desperate, I can give you a patch that provides this capability to any Linus tree.

    • As a member of the GDB team (maintainer of the Linux/i386 port and co-maintainer of the threads support in GDB) I'm not aware of any coordination between the kernel folks an GDB at all. On top of that I'm not inclined to add support for this to GDB until it ends up in Linus' kernel. Anyway, the one-core-file-per-pid approach seems wrong to me. It's a waste of disk space since you're duplicating the VM for every pid. And isn't well suited to how GDB deals with multi-threaded core files on other platforms. A better approach would be to add an additional note with the register contents for each LWP to the same core file.

  • I had no idea so much still needed work (Score:1, Insightful)

    by Anonymous Coward
    So much for being under the impression of a "stable" kernel tree. This really discourages me, and I'm glad all my production machines are using FreeBSD where I can keep track of the CVS-synchronized sources where we don't have competing kernels.
    • The 2.2 series is still the stable kernel, not 2.4, and will probably be so for the next year. Thus spake Mr. Cox on the LKML.

      Yeah, I know it's bogus - 2.3.x should never have been dubbed 2.4 until it was stable (esp. with the rotten VM), but there you have it.

      I tried 2.4 and got bitten by the VM, so am thinking (being lazy) of switching to SuSE who have large file support merged into the 2.2 kernel.
      • well, everyone was pretty pushy about getting the 2.4 kernel out the door. Maybe linux suffered from the hype of the internet economy too?
        • IIRC, Linus never said 2.4.0 was rock-solid. He said something along the lines of "The heck with it. Here it is. Enjoy!"
          • If anyone remembers, back when linux rolled to the spankin' version "1.0", Linus said, "Calm down children. It's just a number." The quote may not be 100% correct as this was many years ago, but the part about the version being "just a number" is as true today as it was then.

            Linus and company may know how to write code, but it's very obvious they were never taught to manage all of their code. Talk about a black art. Linus' hatred of CVS doesn't make things any easier.
            • CVS has well earned it's hate. I'm all for version control, but CVS is an ugly hackish piece of crap. I sure wish Subversion would get completed (or at least releasable). As it is, CVS has too much momentum behind it because it "just works" (or "sorta" works). One of the curses of the Unix mentality (have separate tools which only do one specific thing), is tools that just *barely* do the job enough to scratch the particular developer's itch. Unfortunately version control is not that sexy.
            • Linus' hatred of CVS doesn't make things any easier.

              If Linus hates CVS, why not set up a Perforce server for him? I was recently looking at their web site [perforce.com], and saw that Open Source developers can obtain licenses for FREE!

              It's more powerful than CVS, and has a great user community to help solve problems.

              I just downloaded it, installed it, and started submitting files in about an hour -- and half that was the download (modems suck, especially after having had ADSL, 1-way cable, and 2-way cable).

              No relation to Perforce, just very pleased with their interface and their attitude.

        • I suspect it's just the open-source release schedule - make lots of releases.
      • Well, there's stable and then there's stable... 2.4 was, what, over a year past due for release? How many 1.3 kernel revisions were there before 2.0 was declared?

        A lot of things could be done differently. They, of course, won't because Linus hates CVS. Personally, I'd prefer something along the lines of ClearCase, but I'm paying for the licenses :-) It's time consuming work -- over 50% of work load at Make Systems was configuration management related stuff and there were only a few dozen people working on code.

        Anyone who knows anything about code management knows what a "code freeze" is. They also know to begin working within new branches (long) before freezing previous branches. 2.5 should have been open for development when 2.3 was "frozen". And certainly parts of the current 2.4 tree don't belong there -- bug fixes and isolated back ports from the development branch are all that should be going into the 2.4 line. Additionally, it's hard to construct a schedule when you have no clear direction -- a list of features to be in X and which features are push further down the line.

        Of course, I don't what the kernel versions to start looking like Cisco IOS tags :-)
        • They, of course, won't because Linus hates CVS.

          You should mention to Linus that Perforce [perforce.com] is giving free licenses to Open Source developers; the GNU GPL v2 or higher is sufficient.

          Perforce is very flexible, a great system. Plus there's a great user community.

          One advantage Perforce has over CVS is it groups a number of files into a "submit". A submit is atomic: if anything goes wrong it rolls everything else back. Change numbers describe a submission, then, not a single file. This is very useful -- you can see which files a person touched at once, either to see how he was thinking while working, or if maintenance is required, it's easy to find all the changes that went into his contribution to the source tree -- there all described by a single change number.

    • "Competing" ?
      Without these alternate kernel trees, nothing would ever get done. the -ac trees really aren't a tree I'd recommend for a production server unless it has a fix or driver that the server desperately needs... the -ac's are to test and impliment things in advance to KEEP the "stable" tree "stable", and keep Linus happy that the patches he's putting in the mainstream tree have been tested.

      And no, I don't feel the 2.4 series deserves to be called stable, but I damn well use it anyway on my primary desktop box :)

      Linus, GIVE US 2.5 TO PLAY WITH!
    • Amen, Brother.

      Linux is quite the maelstrom. I cannot fathom why anyone would use Linux on production boxes when other, more stable and reliable OSes are available.

      ~g.
      • > Amen, Brother.
        >
        > Linux is quite the maelstrom. I cannot fathom
        > why anyone would use Linux on production boxes
        > when other, more stable and reliable OSes are
        > available.

        And what are those OSes? FreeBSD, Solaris, s/390?
        And in what situations are they more stable?
        As a firewall/fileserver/desktop?
        I've been using Linux for Prodution boxes and for my personal use for about 3 years in so many ways.
        And this far the only kernel crashes I've had is with the AgpGart and NVdriver kernel modules.
        I'm not saying that *BSD and other OSes aren't more stable in some situations.
        I'm just saying that you made a pointless generalitation!
        • Same here, by sticking to the released kernels I have NEVER had a stability problem outside of the binary nvidia drivers except for a FEW times that were related to VERY specific hardware.
          If you experience crashes/oopses that seem to be related to the kernel, PLEASE PLEASE PLEASE report them with all possible information to the linux-kernel list.


        • Now I don't want to start a flame war here, but when someone says "Linux" what do they mean?

          There are so many distributions, each with little kernel tweaks (RedHat IMHO is especially bad) and different userland applications. So, I have kernel 2.4.9 with what patches, and what userland apps, what compiler, etc.? I'm totally confused. What *is* Linux?

          If I go to kernel.org and download a 30MB tarball of the kernel.... now what about the userland apps? Where do those come from? Who wrote "ps"? What version of "netstat" should I use? Which gcc compiler should I use?

          However, with an OS like FreeBSD... "FreeBSD 4.3-RELEASE" refers to one and only one kernel & userland. No questions. No confusion. If there are problems with a particular version, I can retrieve a CVS snapshot of the kernel and userland sources at any point in time since the beginning of the project. Very impressive.

          ~g.
          • I read somewhere that you should regard the various distributions as distinct, yet fairly compatible OSes.

            Therefore, Red Hat 7.1 is a complete OS with a well defined (perhaps only internally documented) list of utilities/applications at well known individual version stages. Then you can compare RedHat 7.1 with FreeBSD 4.3-RELEASE to find out how they compare.

            To answer your question: Linux is the kernel used by compatible OSes, known as "Linux distributions".


  • When is the MAX_MAP_COUNT fix going to make it into the mainstream kernel?
  • With the -ac tree I try and do rapid rolling releases, sucking in new code to test it and also its interactions with other new code. By doing releases every few days I get a high number of people testing and reporting bugs before there are too many possible causes. This is how Linus trees used to work long ago, and I still think its the better technique.

    Perhaps he meant the unstable series Linus releases. I sure as hell would NOT like to see a new "stable" kernel release every few days. The current faux-schedule of a new release every couple of weeks seems a bit too quick for decent testing to me, to tell you the truth.

    • Re:Wait a minute (Score:4, Informative)

      by Alan Cox ( 27532 ) on Wednesday August 22, 2001 @01:50PM (#2204876) Homepage
      You make an assumption that the right way to test code is in big lumps. That is somethiny any engineer will tell you is bogus.

      You test continually, you test each changeset, and then every so often you run a several day shakedown test.

      You are right that you can't QA a kernel to vendor production grade in two weeks. Some of the RH test runs take several days per run for example.

      • Sure, but sometimes you have to test all at once.

        I've worked on projects before where the hardware was only partially stable, and the rom code was changed daily and normally couldn't boot. Those doing higher level work on the system were forced to write code for the specs, and debug latter. It isn't the best, but it works. (Yes there is simulation, but simulation tends to comment out all the hardware interaction, which changes things drasticly)

      • So you do that in the deveopment tree, not the stable one.

        It's crazy to have stable releases coming out as often as we do. There is no way that you could change enough in the kernel to justify a new stable release 2 weeks (or less) later unless it was a to fix a major oversight (read: bug) in the previous stable release. You just don't have time to test things out.
        • Hmmm... I guess you don't read the changelog very closely do you? More fixes and additions go into each new kernel version than you would find in many updates for commercial closed-source software.
          With most changes, for example, a driver fix, you don't need to test out the whole kernel, just things that deal specificaly with that driver.

          And yes, there are bugs in every "stable" release, there are bugs in every "stable" release of all software.

          Go monitor the changelog and the linux-kernel list for a couple weeks, and you'll understand why stable kernels are released within 2-4 weeks of eachother.And no, monitoring the KernelTraffic summaries DOES NOT COUNT as monitoring linux-kernel, far more goes on than KT summarizes.
      • Okay, I'll stick my foot in some place for which I don't have time to volunteer... :)

        What if the direction was set to "require" developers to submit unit tests for their modules along with them? In not too long it would be possible to *shudder* regression test the entire kernel.

        How is the QA testing of the Red Hat Kernel done now? WOuld it be easier or harder to integrate a test suite into the kernel source itself?
  • No, no, no. The question was, "What happens to AC posts about VALinux and Microsoft?"

  • from the cyfrifiadurol dept... (Score:4, Informative)

    by JJGreenaway ( 194991 ) on Wednesday August 22, 2001 @01:48PM (#2204869) Homepage
    In case anyones wondering 'cyfrifiadurol' isn't a typo. It's Welsh roughly meaning 'to do with computers'.

    And before anyone says it, yes, computers have reached Wales now...
    • And before anyone says it, yes, computers have reached Wales now...

      Better not run Harpoon [harpoon4.com] on them, or Greenpeace [greenpeace.org] will be pissed.
    • > And before anyone says it, yes, computers have reached Wales now

      yeah but the cost of classified ads in the paper is prohibitive when they're looking for programmers in llyncyrfdlywrfldycrlycywwcrynrfrwnr...

      i'd like to buy a vowel.

      (oh crap i think i just called someone's mother a really nasty name)
      • I don't know any Welsh, but from what I do know of other languages and the history of the Latin alphabet I would guess that the Y *is* a vowel, and thus that word seems perfectly pronounceable.
        • I don't know any Welsh, but from what I do know of other languages and the history of the Latin alphabet I would guess that the Y *is* a vowel, and thus that word seems perfectly pronounceable.

          Yeah. I don't know Welsh either, but my grandparents do, and it's not half as unpronouncable as it looks. I guess we're getting offtopic here, but whatever.

          This is the first time in a while there was an ask slashdot that was both interesting (compare to say the Dorm Storm one a while back), and informative (Alan Cox r00lz, though he may not appreciate me saying it in such a manner).

        • W is also a vowel. The ISO 8852 charset designed for Wales contains both W and Y with accents.
        • Heading rapidly further from the topic, I'll confirm that. Its a bloody good job too, otherwise me having a middle name of 'Rhys' would be rather complicated. Mind you, even the word 'by' would be a bit fiddly without the wonder that is using y as a vowel. Welsh uses w as a vowel too, e.g. in 'cwrs', which is perfectly simple to pronounce really.
        • > I would guess that the Y *is* a vowel

          Argh... you "GUESS that the Y *is* a vowel"? Guess again.

          Man, are you american or what? An second question: Has America some sort of IQ-restriction for every citizen. Like, say, a maximum of 5? Even dry bread is smarter than you guys.

          C. M. Burns

          • Re:from the cyfrifiadurol dept... (Score:1, Informative)

            by Anonymous Coward
            Argh... you "GUESS that the Y *is* a vowel"? Guess again.

            I'm not sure what you mean here, but it's obvious that you're a real moron. Some letters have different pronunciations in different languages, and 'y' is one of those. In English it is either vowel or consonant depending on the context, which is actually an orthographic mistake in my opinion. This usage comes from Middle French, though. (French has dropped the 'y' in most places, compare old "roy" with modern "roi.") In Latin, as far as I understand it was always a vowel which was used to represent the 'u' sound like in French (like the 'ue'/u+umlaut sound in German). (That's a front high rounded vowel, for the phonetically informed.) This came from Greek and was used only in writing Greek words, since no native Latin word uses the sound. The same goes for old English. In a popular transcription system for Russian, 'y' represents the letter whick looks roughly like Ib in Russian (high middle unrounded vowel?). In many newer writing systems, such as Wolof (to take one that I speak), 'y' is always a consonant, a palatal glide like in "yes."

            As a more logical alternative, many languages, such as Dutch, German and Polish, have chosen to use 'j' for the sound equivalent to the English consonant 'y'. This is really more sensible, because 'j' is derived from 'i', which in Latin was used for both a consonant and a vowel, like 'y' in modern English. The practice orginated among scribes wishing to make Latin texts more clear, so they added a little curl at the bottom of the i's that were consonants. People in Central Europe picked this up when developing writing systems for their own vernacular langauges.

            So, although I can't say I know any Welsh, I do know a thing or two about languages and alphabets. Why don't you think before you open your fool mouth next time?

  • Ask Slashdot (Score:1, Offtopic)

    by zpengo ( 99887 )
    WTF is going on with the front page?
    • That their database is still Having Issues. We need a story on what's going on there.
      • Yes, indeed it is having problems.... My journal entry was made about 24 hours ago. It was gone this morning so we've had maybe over a day of problems now.

        Give us an update, CT!

        Oh, and ignore the 'game client' link below -- if it is still there. Yesterday it pointed to my journal entry.

    • He has commented about this before on linux-kernel. Search, read, be enlightened.

      For now it's... no, with good reason. IMHO XFS is the best thing sense sliced bread. In very informal testing it works best out of all the jornaling FSs that I have played with.

      • Well, I just searched linux-kernel, to no avail. I can find nothing where the problem with merging XFS is explained.

        I have heard that it has to do with the fact that XFS changes some other things in the kernel outside of the actual filesystem code, but I don't know if that's actually the problem.

        I just hope we don't end up with one or more forks of the kernel because of this.

        • Hmm, well. It was a topic last week. maybe it has not hit the lists yet. basicly it (XFS) changes more then just a few things, and more then a new FS should. I know it makes changes to the VM, and scheduling.

          There was more info then that, but I hate para-phrasing other people.

          Don't you wish there was a built in spell check in slashcode? But then again it keeps me from being too verbose. :>

        • The XFS patch splits into 7 major components:
          1. XFS only code. Approx 4Mb of new files for XFS only.
          2. Easy patches to existing files. These add new functions and definitions which are only used by XFS, plus changes to existing Makefiles. It also changes some VM functions to cater for delayed block allocation which only XFS supports. These changes have no affect on VM except for XFS pages.
          3. Tricky patches to existing files. The extra facilities of XFS require extra parameters on some existing VM functions.
          4. LVM updates. The lvm code in 2.4.x has bugs which XFS trips, so we have to include lvm updates in the XFS patch. With the recent announcment of LVM 1.0 this patch should disappear.
          5. Kernel Debugger. SGI maintain kdb and it is included in the XFS tree for ease of use by the XFS developers.
          6. Miscellaneous patches. These include adding XFS to defconfig, setting EXTRAVERSION, workarounds for kernel bugs such as min/max not handling pointers. It also includes kbuild 2.5 changes, XFS is ready for kbuild 2.5.
          7. Extended attributes and ACLs. XFS optionally supports extended attributes and Attribute Control Lists. This is not a core requirement for XFS and there is at least one other group working on ACLs, so this code is separated from the core XFS.

          Only the first three patch sets are required to get the core XFS functionality. The other four are nice to have but not mandatory. SGI have repeatedly sent the first three sets to Linus, without any response.

          If any kernel distributor (including -ac) wants the individual XFS patches, just ask. SGI do not make them generally available because they are snapshots which are only created as required. The normal method of getting XFS is from CVS or as a release, both of which include all the patch sets.

          • Thanks for the information! I'd sure like to hear from the other side; why do they seem to be ignoring the XFS team?

            I really am very impressed with XFS; it seems like solid, proven code. I think XFS has the best chance at being the heavy-duty file system for Linux.

            • You will probably have to merge XFS into -ac yourself. Some time ago the same question has beeen asked on the linux-xfs mailing list and one of the developers stated that it would be to hard to keep track of the -ac patches. Alan can produce his patches "at an alarming rate" :)

  • I can appreciate the problem (Score:4, Interesting)

    by jd ( 1658 ) <imipakNO@SPAMyahoo.com> on Wednesday August 22, 2001 @01:56PM (#2204900) Homepage Journal
    The FOLK project [sourceforge.net] (gratuitous plug!) runs into all sorts of problems, all the time, from inconsistancies, patch for A being out of sync with patch for B, etc, etc, etc.


    That's one of the reasons I started that project, in the first place. Because it's mind-numbingly tedious to massage patches from different groups together. If you can get the whole thing in one gigantic gloopy splodge, life would be much easier.


    Unfortunately, I've discovered a number of things along the way:

    • Debugging said gloopy splodge is a Royal Pain!
    • Finding others who will help debug said gloopy splodge is not easy.
    • Finding others who will even -report- bugs in said gloopy splodge isn't easy, ether.


    That's not to say that FOLK is a disaster. Quite the opposite! I'm learning a huge amount about the Linux kernel, for a start, and the sheer complexity of juggling hundreds of patches is really giving my C coding skills a workout and a half!


    My hat is off to Alan Cox who not only manages his patch set with far more grace than I ever could, but actually keeps it so that it runs!


    I know the Royal Web Admin uses Linux (cos that was on an interview, some time ago), so if he's reading & has any influence, I honestly think Sir Cox would not be an undeserved title for his amazing computing skills and his contribution to both computing and Britain.

  • I didn't know the -ac trees had Promise IDE RAID support. I looked all over for a good solution for using that thing, after I carefully soldered on my resistor, only to find out that there was no good Linux support for the darned thing. Has anyone had any success using this thing in Linux (not using the closed-source drivers?) This is something I'd really like to see in a stable kernel.. does anybody know how to tell what -ac releases are stable, if any? **pounding head on cubicle wall** I suppose I can use software RAID if that's what it comes down to.

    • Re:Promise IDE RAID (Score:3, Informative)

      by Tony Hoyle ( 11698 )
      The Promise RAID *is* software RAID. All the kernel can give you is access to the extra IDE ports (which is does).
      • I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit. Check out 3Ware if you need hardware IDE Raid. Because it's hardware - you don't have the driver problems.
        • I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit.

          Yeah, same thing with the Abit KT7A-RAID board. Actually IIRC that's a promise board too, just built into the motherboard.

          Those extra ATA/100s are really nice for doing software RAID, though.

    • Re:Promise IDE RAID (Score:2, Informative)

      by Sunthalazar ( 69878 )
      I don't know specifically about the Promise IDE RAID, but I do know about the HPT370 RAID. They are actually included together.
      All I can really say is that it's not quite perfect. I'm using an on-board HPT370 [it's part of my Abit VP-6], and under Win2K I don't think I've had any crashes [well other than some reproducable ones that are things that I've done]
      But I've used the -ac patches in 2.4.6-2.4.8 and so far there is still a couple of times when my machine will just lock up. It seems to be related to disk access, but it also only happens when I'm running X. Without X, I haven't had any problems [although I can't run Mozilla or XMMS, etc without X]
      In general, though, it recognizes and runs fine. I haven't had any general data inconsistency [I run ReiserFS on the RAID partitions]
      Again, this is for the HPT370, not the Promise IDE RAID, but since they are in the same kernel patch, I figured their results would be similar.
    • If you want good hardware raid, get a 3ware [3ware.com] board.
  • At regular intervals I take stuff from the -ac tree and feed it to Linus.

    ...because I need to feed Linus blocks that are debuggable. Thus I don't want to feed Linus both file system and disk driver changes at once...

    I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so.

    So Linus eats code. Everything is so clear now...

  • "At regular intervals I take stuff from the -ac tree and feed it to Linus."

    Take that out of context and think about it.

    • > "At regular intervals I take stuff from the -ac tree and feed it to Linus."

      > Take that out of context and think about it.

      Just because Alan Cox is east of the US doesn't mean he is a snake.

      And why are all of you handing me my coat?

      Geoff
  • I remember claims that Linus what "the CVS with brains", but when there are two trees (AC and Linus) it would seem that CVS is a must.
    What is holding AC and Linus (aside from having to learn how to use CVS)?
    • Even with CVS there would still be two branches and the pain of seperating patches out for merging from one branch to another. Let the patch managers decide if they want to use it. CVS doesn't solve this problem by itself.

      Its worth noting that several subsystems of linux are maintained under their own CVS repositories, with patches being seperated out into functional units and sent to Alan or Linus to sync the project up.
    • They don't want CVS becasue they want people to be able to submit a bug report for a particular kernel. Yeah its a crapy system in some regards, but it allows Linus to have better control on what is and is not worthy of being official kernel. Alot of the really cool stuff in the kernel now suchy as QT and GTK in the frame buffer and kernel Cobra (ok that was just silly) isn't in FreeBSD because FreeBSD development is more "committee" based. Then again FreeBSD is alot easier to admin then most linux distros.
      cvsup -g ${SUPFILE}&& cd /src/src && make world && shutdown -r now
      Linux kernel development is organized in a way to encourage these maverick kernels.
      • I agree with you on the topic of Linux using CVS. BUT, BSD, in its earlier days, was created mainly by Bill Joy. Bill Joy's equivilent (sp?) in the Linux world would be Linus Torvalds. In the early days of BSD, Bill Joy controlled, for the most part, what went in BSD. There wasn't even CVS back that far . . . onc Joy left, then BSD got more "open" to the ideas and patches of others. The same thing may happen with Linux, if and when Linus decides to move on.
        • Well, even if Linus does move on before he dies, I imagine Alan Cox would probably be the most likely candidate to takeover development of the mainstream kernel when Linus decides he's burnt-out. While he probably wouldn't be as conservative as Linus is with it, I don't think things would change too drasticaly.

  • -AC (Score:1)

    by Heem ( 448667 )
    Without -AC it could get pretty -HOT

  • Slashdot researched a submission! Beware, the anti-christ may rise soon!

  • All my confidence in Linux is lost forever (Score:4, Funny)

    by fobbman ( 131816 ) on Wednesday August 22, 2001 @03:04PM (#2205202) Homepage

    What Happens To -AC (And Other) Kernel Mods?

    I'm sorry, but if the kernel has a bunch of modifications done by people who find it necessary to be referred to as the initials for Anonymous Coward then how can we trust the security of the kernel?

    They get modded down on /. but then get merged into the kernel source? Let's make a stand and stick to it!

    Oh, and I copied these comments to a text file so I can repost it in the event that /. pukes up it's guts again.

  • As far as I'm concerned, no anonymous coward has the right to expect his patch to make it into the mainstream kernel. Let's have some accountability, people!


    Nate


    (I'm sorry; I had to do it....)

  • You know, the BSD's solved this long ago by allowing more open modification of the official kernels.
  • Where would on see this ac tree growing? err... I mean where can I find the code tree/patches?
  • I never had as much trouble with the 2.4.5-9 kernels & support for the Athlon CPU. Talk about buggy. I finally had to switch to PIII as CPU before I had a stable kernel again.

    • Re:Athlon CPU support should (EXPERIMENTAL) (Score:1, Informative)

      by Anonymous Coward
      Athlon CPU support is rock solid. Certain combinations of VIA chipset motherboards and AMD Athlon processors seem to leave a lot to be desired

      Avoiding the streaming memory fetches will help on most of those boards (ie optimise for PII or K6)
    • I thought that was a bug in a VIA chipset? I'm pretty sure the Athlon optimization stuff is pretty rock solid and definitely not experimental. I'd hate for them to start slapping the (EXPERIMENTAL) label on anything which might cause problems or conflicts on some specific platforms. (Although that's what MS did with their latest OS, didn't they...)
    • There have been some issues with Athlon optimizations, however you don't have to use Athlon optimizations when compiling your kernel.
      I've had NO trouble with Athlon optimizations in 2.4.7 and 2.4.8 and now 2.4.8-ac9.

      Most of the Athlon problems reported in the past have been problems with VIA's chipsets, which I label as "devil-spawn".
  • Have a look on how FreeBSD does handle this:
    Instead of having only one tree, there are two: the -stable and the -current. -current is the tree with the newest features and active development going on, the tree which might, or might not, compile, the tree which might, or might not, break your system. The -stable tree is the tree in which everything works, which has no real new active development (all development is done in -current), only merges from the -current track are coming back into it.

    For more information, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/current-stable.html [freebsd.org]
    • Instead of having only one tree, there are two: the -stable and the -current.
      You mean even and odd?(2.2 & 2.3, 2.4 & 2.5)
      It's allready there. There isn't any real active development allowed on 2.4, period. It's all fixes and clean ups. Once 2.5 hits then we'll see nifty stuff like a new console subsystem, making everything happy with hotplugging, maybe a few new FS's being merged and other subsystem reorganisations.

      - RustyTaco
    • Uh, this is already done, both in the kernel and in many linux distributions (slackware, debian, even redhat has Rawhide)
      those -preXX kernel versions are the "unstable" releases (so to speak) of the vanilla kernel tree. the odd-numbered kernels are development kernels that don't even come close to being stable enough to be called unstable.

      the -ac kernels are not simply -stable vs -current, a severely unstable patch that might break things isn't going to intentionaly make it into -ac kernels... you could think of -ac kernels as a testbed for future intigration into the mainstream kernel, but that doesn't make it unstable on the level you're talking about with FreeBSD's -current, that level of instability is reserved for the odd-numbered kernel series (i.e. 2.3 and the forthcoming 2.5).

      One does wonder though what clueless businesses that already know odd=unstable for the kernel will think when 3.0 arrives :)
    • The comments about it already being done are not strictly true. ReiserFS was introduced in 2.4.1 after feature freeze. There is no way that you can say ReiserFS was a bugfix. That is big time new development.
  • you can compile the kernel with -ac? "Allow anonymous coward posts"? Reckless!

  • This is very interesting:
    http://www.uwsg.indiana.edu/hypermail/linux/kernel /0108.2/0416.html [indiana.edu]

    It seems Alan Cox is considering his -ac kernel tree to be a legitimate alternative to the official "Linus" tree, rather than a playground for testing patches. He's actually perpetuating a difference between -ac and the official tree, in a way that breaks source compatibility between the two (albeit in a very small way.) The fact that RedHat's kernels are all based on -ac now bears this out.

    Alan has forked the Linux kernel.

    ::meyhem::

    I think he has Linus' blessing in this though. Reading between the lines, I think Alan has been taking on more and more work in the past year or so that had previously been Linus'. Linux is ten years old now; I suppose Linus is burning out.

    And Alan works for RedHat too, which is one of the two distributions that I *know* will be around in ten more years -- they have a solid business plan. Alan is voracious, just tireless, and RedHat would hire the entire core kernel development team if they had to. Linux will not die for lack of a maintainer if Linus gets hit by a bus tomorrow.

Slashdot Top Deals

Life is a whim of several billion cells to be you for a while.

Close