Linux 6.12-rc2 Released With Initial Batch Of Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OneTimeShot
    replied
    Originally posted by mdedetrich View Post

    It shows, if your not bothered you probably shouldn't have even tried


    And you know who is bothered? Kent, which is why kent is helping set up a nightly CI build for fs-next so that these issues don't happen again.
    Wow - HE came up with the idea of running the regression tests before pushing the code and screwing people over? I totally see why Linus was wrong to doubt him now.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by OneTimeShot View Post

    You know... I can't actually be bothered...
    It shows, if your not bothered you probably shouldn't have even tried

    Originally posted by OneTimeShot View Post
    ...but you know what would make me be bothered? If I was working on a file system that I was planning to upstream to Linus Torvalds and hundreds of other people...
    And you know who is bothered? Kent, which is why Kent is helping set up a nightly CI build for fs-next so that these issues don't happen again.
    Last edited by mdedetrich; 07 October 2024, 07:56 AM.

    Leave a comment:


  • OneTimeShot
    replied
    Originally posted by mdedetrich View Post

    Well you have a problem reading, thats for sure. Try running the tests, then report back.
    You know... I can't actually be bothered...

    ...but you know what would make me be bothered? If I was working on a file system that I was planning to upstream to Linus Torvalds and hundreds of other people...

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by OneTimeShot View Post

    Maybe I'm not as dumb as I thought?
    Well you have a problem reading, thats for sure. Try running the tests, then report back.

    Leave a comment:


  • OneTimeShot
    replied
    Originally posted by mdedetrich View Post

    Pro tip, its not just compiling but also running the fs tests, it was runtime behaviour that was broken.


    Actually Linus wasn't right, but you missed that bit so you still clelarly didn't read the lkml
    Done. Took 4 mins on my laptop. I'm guessing the full fs tests would need to run overnight? I probably would have already caught any serious bug just by mounting a filesystem though (what with the problem being the kernel not compiling at all, and everything)... ...would you like me to automate the with a script? It'd probably take me 20mins.

    Maybe I'm not as dumb as I thought?

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by OneTimeShot View Post
    LOL yeah - I'm just a dumb F who knows how to cross compile for multiple platforms, and does so before pushing code. Despite my cluelessness, I also know how to automate it in an overnight. Now I'm gonna push my stupidity to see just how long it takes QEMU to boot a big endian Linux kernel to /bin/bash... Maybe my patience won't wear out after waiting 5 mins.
    Pro tip, its not just compiling but also running the fs tests, it was runtime behaviour that was broken.

    Originally posted by OneTimeShot View Post
    Maybe this guy is so good that gcc can't compile code as fast as he writes it? Or just maybe, Linus is right?
    Actually Linus wasn't right, but you missed that bit so you still clelarly didn't read the lkml. Linus thought that the developers in fs subsystem were actively testing for big-endian when in reality as Kent pointed out, there is a big gap there as no was really testing for that (which is not surprising, almost no one is fuken running big-endien machines).

    XFS has some of their own CI systems for this, but it only tests XFS and nothing else so its not really public.
    Last edited by mdedetrich; 07 October 2024, 07:17 AM.

    Leave a comment:


  • OneTimeShot
    replied
    Originally posted by mdedetrich View Post
    Or maybe as a dumb mortal you can use your brain to read the lkml and realize that this process doesn't work well for experimental features that are being rapidly developed which is exactly where bcachefs stands.

    The current process is okay for code that is essentially in maintanence mode that gets very few changes, but thats not the case for bcachefs.

    LOL yeah - I'm just a dumb F who knows how to cross compile for multiple platforms, and does so before pushing code. Despite my cluelessness, I also know how to automate it in an overnight. Now I'm gonna push my stupidity to see just how long it takes QEMU to boot a big endian Linux kernel to /bin/bash... Maybe my patience won't wear out after waiting 5 mins.

    Maybe this guy is so good that gcc can't compile code as fast as he writes it? Or just maybe, Linus is right?

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by pokeballs View Post
    If bcachefs is evolving so fast that the kernel procedures can't keep up, then it should just keep evolving out-of-tree ?
    Or maybe Linux should set up a nightly CI build for fs-next which literally every other major open source project has.

    Originally posted by pokeballs View Post
    The solution is really simple but someone is blinded by his inflated ego
    Nah your just spreading shit.

    bcachefs was already developed out of kernel for a decade, Kent thought that it was a good opportunity to put it into the kernel under experimental flag, this is entirely standard process.

    Since we are dealing with full featured CoW filsystems, which is one of the most complex and large systems you can think of in an OS there are understandably a big flux of changes. This is also normal. The last time such a massive filesystem got introduced was btrfs, and even though it followed the process that didn't go so well as it slowed down work on btrfs by a lot, and that meant it took much longer for users to get needed fixes/features (which is kind of critical since we are dealing with filesystems).

    The only ones with an ego here is old time linux maintainers as the actual a really simple solution is to setup a CI for nightly build.
    Last edited by mdedetrich; 07 October 2024, 07:10 AM.

    Leave a comment:


  • pokeballs
    replied
    If bcachefs is evolving so fast that the kernel procedures can't keep up, then it should just keep evolving out-of-tree ?

    The solution is really simple but someone is blinded by his inflated ego

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by OneTimeShot View Post

    Actual TLDR - other people do this just fine. I used to do it myself in the past, and computers are much faster today. It's not like you sit and watch the code build. If this guy is as smart and godlike as everyone says, why doesn't he know how to set up Jenkins, QEMU, unit tests and cross compilation? It only took me a week or two.
    Read the fuken mailing list. Hes not talking about setting up qemu, he is talking about how long it takes the filesystem tests to run in qemu which for something that needs to be purely emulated takes an insanely long amount of time.

    Its so long that there is an ancient 1990's s390x mainframe (which is big-endian) sitting somewhere doing builds instead because its much faster, but this isn't being run nightly against fs-next which is the problem

    Originally posted by OneTimeShot View Post
    Or maybe he could, you know, just work with the dumb process like the rest of us mortals have to?
    Or maybe as a dumb mortal you can use your brain to read the lkml and realize that this process doesn't work well for experimental features that are being rapidly developed which is exactly where bcachefs stands, it is marked as experimental after all.

    The current process is okay for code that is essentially in maintanence mode that gets very few changes, but thats not the case for bcachefs.
    Last edited by mdedetrich; 07 October 2024, 07:04 AM.

    Leave a comment:

Working...
X