Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on 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.

102 of 164 comments (clear)

  1. Post-Mortem debugging of multithreaded processes by sllort · · Score: 5, Interesting

    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!

  2. I had no idea so much still needed work by Anonymous Coward · · Score: 1, Insightful

    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.

    1. Re:I had no idea so much still needed work by SpinyNorman · · Score: 1

      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.

    2. Re:I had no idea so much still needed work by Mr.Phil · · Score: 2

      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?

    3. Re:I had no idea so much still needed work by NNKK · · Score: 2, Interesting

      "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!

    4. Re:I had no idea so much still needed work by Cro+Magnon · · Score: 1

      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!"

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
    5. Re:I had no idea so much still needed work by krogoth · · Score: 1

      I suspect it's just the open-source release schedule - make lots of releases.

      --

      They that quote Benjamin Franklin on liberty and safety deserve neither.
    6. Re:I had no idea so much still needed work by gaydot · · Score: 1

      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.

    7. Re:I had no idea so much still needed work by Dacobi · · Score: 1

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

      --
      .NOT
    8. Re:I had no idea so much still needed work by NNKK · · Score: 1

      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.

    9. Re:I had no idea so much still needed work by gaydot · · Score: 2, Insightful



      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.

    10. Re:I had no idea so much still needed work by Cramer · · Score: 2

      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.

    11. Re:I had no idea so much still needed work by NNKK · · Score: 1

      ahh yes, the usability that doesn't allow you such things as right clicking on the taskbar to change settings...

      if you're going to troll by calling a Windows system more usable than linux, at least use something PLAUSABLE, like win98, in your examples...

    12. Re:I had no idea so much still needed work by Cramer · · Score: 2

      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 :-)

    13. Re:I had no idea so much still needed work by Hard_Code · · Score: 2

      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.

      --

      It's 10 PM. Do you know if you're un-American?
    14. Re:I had no idea so much still needed work by Cramer · · Score: 1

      Have you ever used ClearCase from Rational Software (Atria, whatever)? It's very sexy. That is, for any org that cares about source code management.

    15. Re:I had no idea so much still needed work by Thing+1 · · Score: 1
      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, 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 feel fantastic, and I'm still alive.
    16. Re:I had no idea so much still needed work by Thing+1 · · Score: 1
      They, of course, won't because Linus hates CVS.

      You should mention to Linus that Perforce 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.

      --
      I feel fantastic, and I'm still alive.
    17. Re:I had no idea so much still needed work by Tony-A · · Score: 1

      Nah, Windows 95, the patched OEM version. (The stable Windows 95 that you couldn't buy from Microsoft ;-) It's been downhill ever since.

  3. Yeah but by Frequanaut · · Score: 1



    When is the MAX_MAP_COUNT fix going to make it into the mainstream kernel?

    1. Re:Yeah but by Alan+Cox · · Score: 5, Interesting

      The goal there is to make it unneccessary. 2.4.8-ac7/ac8 have slightly smarter VM merging behaviour done by Ben LaHaise for example.

  4. Wait a minute by bconway · · Score: 2

    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.

    --
    Interested in open source engine management for your Subaru?
    1. Re:Wait a minute by Alan+Cox · · Score: 4, Informative

      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.

    2. Re:Wait a minute by bluGill · · Score: 2

      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)

    3. Re:Wait a minute by spudnic · · Score: 2

      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.

      --
      load "linux",8,1
    4. Re:Wait a minute by binford2k · · Score: 1

      I hope you aren't serious. If you are, then you are a complete paranoid dumbass.

    5. Re:Wait a minute by NNKK · · Score: 1

      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.

  5. Re:Post-Mortem debugging of multithreaded processe by scorpioX · · Score: 3, Informative

    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.

  6. Alan misunderstood the question by DonkPunch · · Score: 1

    No, no, no. The question was, "What happens to AC posts about VALinux and Microsoft?"

    --

    Save the whales. Feed the hungry. Free the mallocs.
  7. from the cyfrifiadurol dept... by JJGreenaway · · Score: 4, Informative

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

    1. Re:from the cyfrifiadurol dept... by Syberghost · · Score: 1

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

      Better not run Harpoon on them, or Greenpeace will be pissed.

    2. Re:from the cyfrifiadurol dept... by scrytch · · Score: 3, Funny

      > 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've finally had it: until slashdot gets article moderation, I am not coming back.
    3. Re:from the cyfrifiadurol dept... by LatJoor · · Score: 1

      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.

    4. Re:from the cyfrifiadurol dept... by randombit · · Score: 1
      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).

    5. Re:from the cyfrifiadurol dept... by shippo · · Score: 1

      W is also a vowel. The ISO 8852 charset designed for Wales contains both W and Y with accents.

    6. Re:from the cyfrifiadurol dept... by iainl · · Score: 1

      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 Know You Are But What Am I?"
    7. Re:from the cyfrifiadurol dept... by CMBurns · · Score: 1

      > 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

    8. Re:from the cyfrifiadurol dept... by Anonymous Coward · · Score: 1, Informative

      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?

  8. Ask Slashdot by zpengo · · Score: 1, Offtopic

    WTF is going on with the front page?

    --


    Got Rhinos?
  9. I think by wiredog · · Score: 2

    That their database is still Having Issues. We need a story on what's going on there.

    --

    Best Slashdot Co
  10. How about getting XFS in -ac? by Brian+Knotts · · Score: 1

    Please?

    1. Re:How about getting XFS in -ac? by Dante · · Score: 1

      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.

      --
      "think of it as evolution in action"
    2. Re:How about getting XFS in -ac? by Brian+Knotts · · Score: 1
      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.

    3. Re:How about getting XFS in -ac? by Dante · · Score: 1

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

      --
      "think of it as evolution in action"
    4. Re:How about getting XFS in -ac? by Keith+Owens · · Score: 1
      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.

    5. Re:How about getting XFS in -ac? by Brian+Knotts · · Score: 2
      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.

    6. Re:How about getting XFS in -ac? by Martin+Maciaszek · · Score: 1

      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" :)

  11. I can appreciate the problem by jd · · Score: 4, Interesting
    The FOLK project (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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:I can appreciate the problem by 4of12 · · Score: 2

      Lameness filter encountered. Post aborted!

      Thanks. I'll keep my thoughts to myself from now on. Between this Innovation® and the new unavoidable link to the front page of the site that started to afflict "older stuff" I'm about ready to fugged about /. entirely.

      --
      "Provided by the management for your protection."
    2. Re:I can appreciate the problem by jbreker · · Score: 1

      get a bigger monitor. can you say 21" display baby

    3. Re:I can appreciate the problem by wolf- · · Score: 1

      I hear you.
      Comments not being accepted for lameness, or because I type too quickly, or a missing field or some ass error.

      Who let this new slashcode into a production environment? Was it ever really tested?

      /me thinks it wasn;t

      --
      ----- LoboSoft specializes in Digital Language Lab
  12. Promise IDE RAID by blackwizard · · Score: 2

    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.

    1. Re:Promise IDE RAID by Tony+Hoyle · · Score: 3, Informative

      The Promise RAID *is* software RAID. All the kernel can give you is access to the extra IDE ports (which is does).

    2. Re:Promise IDE RAID by Sunthalazar · · Score: 2, Informative

      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.

    3. Re:Promise IDE RAID by zulux · · Score: 1

      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.

      --

      Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

    4. Re:Promise IDE RAID by ahodgson · · Score: 1

      If you want good hardware raid, get a 3ware board.

    5. Re:Promise IDE RAID by EvlG · · Score: 2

      That is because the highpoint chips are crap.

      I had a HPT366 in my Abit BE6 and have had nothing but problems with it. I won't buy another board that uses a highpoint - they are junk.

    6. Re:Promise IDE RAID by randombit · · Score: 1

      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.

  13. Don't Feed the Linus by grammar+fascist · · Score: 2, Funny

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

    --
    I got my Linux laptop at System76.
    1. Re:Don't Feed the Linus by Red+Moose · · Score: 2, Funny

      Didn't you know? Linus is like that dolphin from Johnny Mnemonic, only he's a penguin instead. And he's got loads of hi-tec stuff strapped on his head and can track submarines and doing linux is only a part-time thing, really.

      --

      Acting stupid isn't much fun when there's someone around who knows better

    2. Re:Don't Feed the Linus by ethereal · · Score: 2, Funny

      So does that mean Alan Cox is really Ice-T? [shudder]

      --

      Your right to not believe: Americans United for Separation of Church and

  14. Ahem. by nomis80 · · Score: 1

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

    Take that out of context and think about it.

  15. Why aren't you guys using CVS? by sds · · Score: 1

    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)?

    1. Re:Why aren't you guys using CVS? by Splork · · Score: 1

      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.

    2. Re:Why aren't you guys using CVS? by j-pimp · · Score: 1

      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.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    3. Re:Why aren't you guys using CVS? by elbles · · Score: 1

      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.

    4. Re:Why aren't you guys using CVS? by NNKK · · Score: 1

      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.

  16. Re:Post-Mortem debugging of multithreaded processe by n0ano · · Score: 5, Informative
    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.

    --
    Don Dugger
    "Censeo Toto nos in Kansa esse decisse." - D. Gale
  17. Re:Post-Mortem debugging of multithreaded processe by cnkeller · · Score: 2

    Someone mod this parent up. Seems like a worthwhile patch.

    --

    there are no stupid questions, but there are a lot of inquisitive idiots

  18. -AC by Heem · · Score: 1

    Without -AC it could get pretty -HOT

    --
    Don't Tread on Me
  19. OMG!!!! by siliconvortex · · Score: 1

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

  20. All my confidence in Linux is lost forever by fobbman · · Score: 4, Funny

    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.

    1. Re:All my confidence in Linux is lost forever by jbreker · · Score: 1

      ahh im pretty sure that ac stands for Alan Cox. maybe not but its a guess.

    2. Re:All my confidence in Linux is lost forever by Cyno · · Score: 1

      I'm just glad the moderation system on /. doesn't decide which patches get added to the linux kernel. Just imagine how buggy linux would become if we all had a say in what gets added and what doesn't. But perhaps we'd get linux to beat windows in 3d frame rates and downtime.

  21. (OT)Slashdot does not censor. by yerricde · · Score: 1

    There's a big double yellow line with orange traffic cones between improving signal-to-noise and censorship. Slashdot is slalom-skating it.

    Ever since CmdrTaco and friends created the moderation system, Slashdot has intentionally deleted exactly one comment, and it was a flagrant copyright infringement. If you browse Slashdot at -1, you'll see everything.

    --
    Will I retire or break 10K?
    1. Re:(OT)Slashdot does not censor. by Rick+the+Red · · Score: 1, Offtopic
      Then where's the Parent to this comment (#2204931)? What's its number, so we can all read it? If you check the "Parent" link in that comment, you'll see it points to comment zero (0). Either the parent has been deleted, or the "Parent" link has been altered. Now, who can make changes like that around here...? Can you? I sure can't!

      --
      If all this should have a reason, we would be the last to know.
    2. Re:(OT)Slashdot does not censor. by NullAndVoid · · Score: 1

      Elvis did it.

      --


      -- Sigs are for losers
    3. Re:(OT)Slashdot does not censor. by Teancom · · Score: 1

      I've noticed many, many, comments with abortive parents, that couldn't possibly have been offensive and/or libelous. I would guess that they are having problems with their database or code, both of which are brand new (if you haven't seen the couple stories on it lately). Much more likely than all of a sudden a /. editor going on a rampage with the delete key.

  22. AC patches: who needs 'em? by n8willis · · Score: 1
    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....)

    --
    -- Watch the REAL Jon Katz.
  23. Re:I think ... it ate my journal entry! by Sun+Tzu · · Score: 2

    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.

    --
    Geeky modern art T-shirts
  24. The BSDs solved this long ago by howardjp · · Score: 1

    You know, the BSD's solved this long ago by allowing more open modification of the official kernels.

  25. A Canonical Response by llywrch · · Score: 2

    > "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 think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
  26. ac tree... by jmccay · · Score: 1

    Where would on see this ac tree growing? err... I mean where can I find the code tree/patches?

    --
    At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
    1. Re:ac tree... by abdulwahid · · Score: 1

      You can find Alan's kernel patches Here

      --
      perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
  27. Athlon CPU support should (EXPERIMENTAL) by WyldOne · · Score: 1

    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.

    --

    make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
    1. Re:Athlon CPU support should (EXPERIMENTAL) by Anonymous Coward · · Score: 1, Informative

      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)

    2. Re:Athlon CPU support should (EXPERIMENTAL) by OblongPlatypus · · Score: 2

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

      --
      -- If no truths are spoken then no lies can hide --
    3. Re:Athlon CPU support should (EXPERIMENTAL) by NNKK · · Score: 1

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

  28. -stable vs -current ? by MavEtJu · · Score: 1

    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

    --
    bash$ :(){ :|:&};:
    1. Re:-stable vs -current ? by RustyTaco · · Score: 1
      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
    2. Re:-stable vs -current ? by NNKK · · Score: 1

      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 :)

    3. Re:-stable vs -current ? by Builder · · Score: 1

      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.

  29. you can do WHAT?!?! by bungatron · · Score: 1

    you can compile the kernel with -ac? "Allow anonymous coward posts"? Reckless!

  30. Re:Post-Mortem debugging of multithreaded processe by Mark+Kettenis · · Score: 2, Informative

    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.

  31. Alan's Kernel is becoming more "official" by trevorcor · · Score: 2, Interesting

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

    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.

    --
    "That's all I have to say about that" --Forrest Gump
  32. Unit testing? (was Re:Wait a minute) by ulmer · · Score: 1

    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?

  33. Re:Something I'd like to see... by autechre · · Score: 1

    Eek! No! Use of amd is not exactly encouraged any more; you should really be using autofs. You need to compile support for this in the kernel, and your distribution should have the userspace tools.

    --
    WMBC freeform/independent online radio.
  34. HPT366 needs hdparm for stability by korpiq · · Score: 2

    This is what I use with an external HPT366 to have it run stable:

    /sbin/hdparm -c 3 -m 16 -u 0

    cheers

    --

    I think, therefore thoughts exist. Ego is just an impression.
  35. Re:Don't be a playa hata by Glanz · · Score: 1

    Thanks COWARD, or do you prefer Anonymous.

    --
    Rien n'est plus beau que le creux du 0.
  36. Linux distributions by oli_freyr · · Score: 1

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

  37. Re:Random Crap by londenberg · · Score: 1

    In particular I was interested in seeing what messages would show up for me in the new Slashdot messenging system. I got notes for both time I was mod'ed -1 Offtopic, and notifying me of your reply.

    Thank you for you assistance in my (not so) scientific experiment.

  38. Re: The Truth About CmdrTaco, VA, and Microsoft by Tony-A · · Score: 1

    Some things are too important to be taken seriously. /. seems to me more like a soap opera, and just as addictive.