6 ms·

It's great to see all these new features entering the kernel. Here are a couple of other things I've seen in recent changelogs: - The 5.4 kernel can use CIFS a

It's great to see all these new features entering the kernel. Here are a couple of other things I've seen in recent changelogs: - The 5.4 kernel can use CIFS as a root filesystem, meaning CIFS can replace NFS for diskless boot. - The 5.3 and 5.4 kernels both include prep for merging PREEMPT_RT into mainline. This will be a fantastic addition that benefits embedded Linux nerds like me.

lucb1e 7y ago
For more info on the second point: https://en.wikipedia.org/wiki/Linux_kernel#Preemption https://en.wikipedia.org/wiki/Linux_kernel#Preemption seems to have something to do with real-time operating systems, but I didn't dive into it. Edit: Thanks for the downvotes without commenting what I should do differently next time?
- zozbot234 7y ago
  Having preemption throughout the whole kernel helps with everything Low-Latency whether on desktop, mobile or server systems; it's not limited to the traditional real-time use case, although it might obviously help there as well to some extent.
- hactually 7y ago
  It aims to turn Linux into a real-time OS. The preempty patchset aims to give faster response times but the main focus is to remove all unbounded latencies - for example, situations where the delay can vary depending on other factors.
  - jschwartzi 7y ago
    This would kill most use cases for QNX+POSIX.
    - zozbot234 7y ago
      You'll still need QNX if you want to run a full GUI Unix-like OS from a single floppy disk.
      - nineteen999 7y ago
        That hasn't been the case for several years now has it, since perhaps QNX v4? If not, you'll need a time machine as well. http://toastytech.com/guis/qnxdemo.html http://toastytech.com/guis/qnxdemo.html http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm
      - jcelerier 7y ago
        Recent QNX has removed Photon and encourages the use of Qt instead which while can be made small, certainly does not fit in 1.44mb especially in 64bit
        ahartmetz 7y ago
        Yeah, the usual size for a minimal Qt with either QWidgets or Qt Quick / QML is about 15 MB.
      - collyw 7y ago
        Do people still have this requirement in 2020?
    - pjmlp 7y ago
      Usually such use cases require a certain level of certification and security that Linux doesn't offer.
  - ibotty 7y ago
    It's not strictly true that the rt-patchset is meant to give faster response times. It provides bounded response times. You get a guarantee that some code can run within the time frame that you specify. That's not necessarily faster.
    - galangalalgol 7y ago
      I was at a meeting with people that were doing signal processing in "embedded" environments. They said the patch slowed them down a lot. They got better performance and more determanism even, by pinning processes to cores using prior knowledge.
- ausjke 7y ago
  There are quite some people at HN just enjoy downvoting in my opinion. Any critic thoughts, any neutral comments, any doubtful questions, or some grammar mistakes and mis-spells will all be downvoted by them easily! You have to be very insightful, positive, politically correct etc to avoid that fate. For me even though I know I'm going to be downvoted I will still say what I want to say, including this very comment here.
  - lucb1e 7y ago
    I didn't (and can't, because you replied to me) downvote, but since the downvoters are not sharing their reason, I guess I'll share my thoughts on it: I think the "quite some people at HN just enjoy downvoting" is potentially offensive as well as an overgeneralization, and they probably don't like either or both. Aaaand downvotes for this as well, so I guess that means this is not it?
    - cyphar 7y ago
      It's because discussing downvotes is against the HN Guidelines[1]: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Folks downvote comments about downvoting because it's boring to read, and to discourage others from doing it. [1]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - rvz 7y ago
        Well, you're now discussing about "downvoting" and by that logic, you are now breaking the HN Guidelines.
      - deleted 7y ago
        [deleted]
    - g82918 7y ago
      The down votes were because you clearly didn't understand what preemption(or that this is really about it being a realtime flag) is or add much to the conversation(mentioning anything at all that might add something, like even a bad question, "I heard people using raspberry pis for embedded, would this help?"). The downvotes on the other guy are because asking for feedback on downvotes is discouraged. To contribute, the PREEMPT_RT has been around as a set of patches(if not this specific one, then at least some version of making linux a realtime os.). If you need to know that something will run within a specified amount of time realtime matters. EDIT: Don't use this and think it will help performance, generally it kills throughput.
- ronjouch 7y ago
  About PREEMPT_RT merge prep: are we talking about the patchset that leads to ultra-low-latency audio-friendly kernels tagged -rt, like https://aur.archlinux.org/packages/linux-rt/ https://aur.archlinux.org/packages/linux-rt/ or https://aur.archlinux.org/packages/linux-rt-bfq/ https://aur.archlinux.org/packages/linux-rt-bfq/ ? If so, I use these for pro audio (for live dsp / effects under 5ms), and have a few questions: - Will these kernels become obsolete/unnecessary with the merge? - What about BFQ, is it going to be merged at the same time too? - This patchset has been existing for a long time. What prevented an earlier merge? - Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"?
  - mlyle 7y ago
    > Will these kernels become obsolete/unnecessary with the merge? If it merges, sure. It's nice to see it may be getting close. > What about BFQ, is it going to be merged at the same time too? BFQ merged a couple of years ago. > This patchset has been existing for a long time. What prevented an earlier merge? It's been scary in the amount of things it touches and the amount of semantics it changes. It's a big change in mindset. Many drivers have been broken or simply unsupported at times on the preempt-rt branches. More and more of the underlying infrastructure has made it in over the past couple years. > Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"? Nope... the most we can say is it is "close".
    - ronjouch 7y ago
      Thanks. > "BFQ merged a couple of years ago." Okay, got it. My question was driven by confusion of what exactly was package https://aur.archlinux.org/packages/linux-rt-bfq/ https://aur.archlinux.org/packages/linux-rt-bfq/ . Reading now the wiki in GitHub ( https://github.com/sirlucjan/bfq-mq-lucjan/wiki https://github.com/sirlucjan/bfq-mq-lucjan/wiki ), it's clear: > Development version of BFQ > The development version of BFQ [...] differs from the production version in that: > - it contains commits not available for that kernel version; > - it contains a lot of consistency checks to detect possible malfunctions. So, linux-rt-bfq is linux-rt, sprinkled with extra fixes to bfq unmerged yet to mainline.
- _arvin 7y ago
  It's essentially just applying these patches: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.4/ https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt... The above is for kernel 5.4, as the patchset for 5.5 doesn't exist at the time of this post. After applying the patches, you'll want to run "make nconfig" or "make menuconfig" and search for CONFIG_PREEMPT_RT and enable it and you should be good to go. The only downside in my experience is Virtual Box doesn't work with the -rt kernel as of right now, so I can't use it as my daily driver. It is a my preferred kernel though for gaming and overall desktop use. I use a custom low-latency kernel when I'm not using the -rt and it's been working well for me.
- infinity0 7y ago
  Random feedbackless downvoting is more and more being clearly abused to censor seemingly random and perfectly acceptable comments. The fact that talking about it is against the site guidelines only makes the problem worse. HN needs to deal with this. PG seems to understand that a community censorship mechanism needs safeguards. From http://www.paulgraham.com/hackernews.html http://www.paulgraham.com/hackernews.html : > I think it's important that a site that kills submissions provide a way for users to see what got killed if they want to. That keeps editors honest, and just as importantly, makes users confident they'd know if the editors stopped being honest. HN users can do this by flipping a switch called showdead in their profile. How can editors be "kept honest" if a bunch of their minions can just downvote users for no reason and any complaining is forbidden?
  - dhimes 7y ago
    it's not "minions." Way way way back in the early days of the board we actually discussed what downvotes should mean. Argument 1 was that a vote should only indicate whether or not you thought a comment contributed to the discussion- and not indicate agreement or disagreement. This gave an indicator with a single purpose. Argument 2 was that a vote could also be used to indicate disagreement. This made one indicator mean more than one thing. Some suggested a second vote- in order to keep the indicators clear on what they were reporting. pg eventually came down on the side of Argument 2, so voting can be either "I disagree" or "you comment is not useful." I do agree that adding a comment when downvoting is useful to the downvotee, but alas sometimes these come off as mean or supercilious and leave a bad tone in general, spoiling the conversation (or igniting a flame war).
    - infinity0 7y ago
      More and more often recently, I find downvoted comments that I thought are all perfectly useful and reasonable to the discussion. I in fact thought the downvotes were neither "useful" nor "contributing to the discussion". I would rather like to downvote the downvoters to reduce their karma and their power to perform these downvotes, but the only mechanic I have on HN to express my preference is to re-upvote the comment, which is not in fact its original intended purpose. Rather, I would like to ignore all downvotes made by particular downvoters because I believe their judgements are highly flawed, independent of the quality of the original comment that was downvoted. https://abstrusegoose.com/527 https://abstrusegoose.com/527 is highly relevant.
- devit 7y ago
  Currently the Linux kernel disables preemption inside spinlocks and interrupt handlers, and these code sections are not necessarily carefully written to be short and constant-time, so you can in theory get in a situation where all cores are running spinlock or interrupt handler code from low priority threads for arbitrarily long times, preventing higher priority realtime threads to run (which in practice means that whatever hardware you are controlling will be uncontrolled, and thus your self-driving car, rocket, plane or industrial machine might be destroyed). The PREEMPT_RT patch solves this by reimplementing all kernel spinlocks as mutexes with priority inheritance that are fully preemptible and all interrupt handlers as preemptable threads. The result is that if you have a bunch of real-time process/thread that do not make system calls, it's guaranteed that in a bounded amount time the highest priority set will be running. If you do however make system calls (or even if you cause page faults because you didn't call mlockall() and accessed non-mlocked memory), with the exception of some system calls that provide better guarantees, then you can still have kernel spinlock contention with other threads that may hold the same spinlock for an unbounded amount of time, so the system is more limited than dedicated real-time OSes that are careful about this.
  - deleted 7y ago
    [deleted]
zdw 7y ago
I wasn't able to find documentation for using CIFS as / - is there a guide somewhere? What are the advantages of this as compared with NFS?
- pkaye 7y ago
  CIFS is I think the protocol used on Windows and SAMBA.
  - jagger27 7y ago
    Yes, ish. CIFS is the protocol that came before SMB, but people still use the term to describe modern Windows SMB or Samba.
    - burfog 7y ago
      SMB was first. CIFS is a rebranding that happened when Microsoft was forced to release documentation for the protocol.
      - derefr 7y ago
        Yes, but CIFS was a rebranding of SMB1; successive versions of SMB have just been called SMB. So first there was SMB, and then CIFS, and then (and now) it's all been just SMB. The only ones still using the term "CIFS" at this point are the Linux/Samba folks.
        burfog 7y ago
        It's a case of running the Common Internet File System on top of the Server Message Block protocol. SMB isn't just for filesystems. It is also used for printing, among other things. CIFS is the filesystem. Outside of Linux/Samba folks, neither term is popular. Users say "Windows share" or "shared drive" or "network folder" or something like that.
    - blattimwind 7y ago
      Don't see someone call SMB "modern" every day...

lucb1e 7y ago

For more info on the second point: https://en.wikipedia.org/wiki/Linux_kernel#Preemption https://en.wikipedia.org/wiki/Linux_kernel#Preemption seems to have something to do with real-time operating systems, but I didn't dive into it. Edit: Thanks for the downvotes without commenting what I should do differently next time?

zozbot234 7y ago
Having preemption throughout the whole kernel helps with everything Low-Latency whether on desktop, mobile or server systems; it's not limited to the traditional real-time use case, although it might obviously help there as well to some extent.
hactually 7y ago
It aims to turn Linux into a real-time OS. The preempty patchset aims to give faster response times but the main focus is to remove all unbounded latencies - for example, situations where the delay can vary depending on other factors.
- jschwartzi 7y ago
  This would kill most use cases for QNX+POSIX.
  - zozbot234 7y ago
    You'll still need QNX if you want to run a full GUI Unix-like OS from a single floppy disk.
    - nineteen999 7y ago
      That hasn't been the case for several years now has it, since perhaps QNX v4? If not, you'll need a time machine as well. http://toastytech.com/guis/qnxdemo.html http://toastytech.com/guis/qnxdemo.html http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm
    - jcelerier 7y ago
      Recent QNX has removed Photon and encourages the use of Qt instead which while can be made small, certainly does not fit in 1.44mb especially in 64bit
      - ahartmetz 7y ago
        Yeah, the usual size for a minimal Qt with either QWidgets or Qt Quick / QML is about 15 MB.
    - collyw 7y ago
      Do people still have this requirement in 2020?
  - pjmlp 7y ago
    Usually such use cases require a certain level of certification and security that Linux doesn't offer.
- ibotty 7y ago
  It's not strictly true that the rt-patchset is meant to give faster response times. It provides bounded response times. You get a guarantee that some code can run within the time frame that you specify. That's not necessarily faster.
  - galangalalgol 7y ago
    I was at a meeting with people that were doing signal processing in "embedded" environments. They said the patch slowed them down a lot. They got better performance and more determanism even, by pinning processes to cores using prior knowledge.
ausjke 7y ago
There are quite some people at HN just enjoy downvoting in my opinion. Any critic thoughts, any neutral comments, any doubtful questions, or some grammar mistakes and mis-spells will all be downvoted by them easily! You have to be very insightful, positive, politically correct etc to avoid that fate. For me even though I know I'm going to be downvoted I will still say what I want to say, including this very comment here.
- lucb1e 7y ago
  I didn't (and can't, because you replied to me) downvote, but since the downvoters are not sharing their reason, I guess I'll share my thoughts on it: I think the "quite some people at HN just enjoy downvoting" is potentially offensive as well as an overgeneralization, and they probably don't like either or both. Aaaand downvotes for this as well, so I guess that means this is not it?
  - cyphar 7y ago
    It's because discussing downvotes is against the HN Guidelines[1]: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Folks downvote comments about downvoting because it's boring to read, and to discourage others from doing it. [1]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - rvz 7y ago
      Well, you're now discussing about "downvoting" and by that logic, you are now breaking the HN Guidelines.
    - deleted 7y ago
      [deleted]
  - g82918 7y ago
    The down votes were because you clearly didn't understand what preemption(or that this is really about it being a realtime flag) is or add much to the conversation(mentioning anything at all that might add something, like even a bad question, "I heard people using raspberry pis for embedded, would this help?"). The downvotes on the other guy are because asking for feedback on downvotes is discouraged. To contribute, the PREEMPT_RT has been around as a set of patches(if not this specific one, then at least some version of making linux a realtime os.). If you need to know that something will run within a specified amount of time realtime matters. EDIT: Don't use this and think it will help performance, generally it kills throughput.
ronjouch 7y ago
About PREEMPT_RT merge prep: are we talking about the patchset that leads to ultra-low-latency audio-friendly kernels tagged -rt, like https://aur.archlinux.org/packages/linux-rt/ https://aur.archlinux.org/packages/linux-rt/ or https://aur.archlinux.org/packages/linux-rt-bfq/ https://aur.archlinux.org/packages/linux-rt-bfq/ ? If so, I use these for pro audio (for live dsp / effects under 5ms), and have a few questions: - Will these kernels become obsolete/unnecessary with the merge? - What about BFQ, is it going to be merged at the same time too? - This patchset has been existing for a long time. What prevented an earlier merge? - Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"?
- mlyle 7y ago
  > Will these kernels become obsolete/unnecessary with the merge? If it merges, sure. It's nice to see it may be getting close. > What about BFQ, is it going to be merged at the same time too? BFQ merged a couple of years ago. > This patchset has been existing for a long time. What prevented an earlier merge? It's been scary in the amount of things it touches and the amount of semantics it changes. It's a big change in mindset. Many drivers have been broken or simply unsupported at times on the preempt-rt branches. More and more of the underlying infrastructure has made it in over the past couple years. > Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"? Nope... the most we can say is it is "close".
  - ronjouch 7y ago
    Thanks. > "BFQ merged a couple of years ago." Okay, got it. My question was driven by confusion of what exactly was package https://aur.archlinux.org/packages/linux-rt-bfq/ https://aur.archlinux.org/packages/linux-rt-bfq/ . Reading now the wiki in GitHub ( https://github.com/sirlucjan/bfq-mq-lucjan/wiki https://github.com/sirlucjan/bfq-mq-lucjan/wiki ), it's clear: > Development version of BFQ > The development version of BFQ [...] differs from the production version in that: > - it contains commits not available for that kernel version; > - it contains a lot of consistency checks to detect possible malfunctions. So, linux-rt-bfq is linux-rt, sprinkled with extra fixes to bfq unmerged yet to mainline.
_arvin 7y ago
It's essentially just applying these patches: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.4/ https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt... The above is for kernel 5.4, as the patchset for 5.5 doesn't exist at the time of this post. After applying the patches, you'll want to run "make nconfig" or "make menuconfig" and search for CONFIG_PREEMPT_RT and enable it and you should be good to go. The only downside in my experience is Virtual Box doesn't work with the -rt kernel as of right now, so I can't use it as my daily driver. It is a my preferred kernel though for gaming and overall desktop use. I use a custom low-latency kernel when I'm not using the -rt and it's been working well for me.
infinity0 7y ago
Random feedbackless downvoting is more and more being clearly abused to censor seemingly random and perfectly acceptable comments. The fact that talking about it is against the site guidelines only makes the problem worse. HN needs to deal with this. PG seems to understand that a community censorship mechanism needs safeguards. From http://www.paulgraham.com/hackernews.html http://www.paulgraham.com/hackernews.html : > I think it's important that a site that kills submissions provide a way for users to see what got killed if they want to. That keeps editors honest, and just as importantly, makes users confident they'd know if the editors stopped being honest. HN users can do this by flipping a switch called showdead in their profile. How can editors be "kept honest" if a bunch of their minions can just downvote users for no reason and any complaining is forbidden?
- dhimes 7y ago
  it's not "minions." Way way way back in the early days of the board we actually discussed what downvotes should mean. Argument 1 was that a vote should only indicate whether or not you thought a comment contributed to the discussion- and not indicate agreement or disagreement. This gave an indicator with a single purpose. Argument 2 was that a vote could also be used to indicate disagreement. This made one indicator mean more than one thing. Some suggested a second vote- in order to keep the indicators clear on what they were reporting. pg eventually came down on the side of Argument 2, so voting can be either "I disagree" or "you comment is not useful." I do agree that adding a comment when downvoting is useful to the downvotee, but alas sometimes these come off as mean or supercilious and leave a bad tone in general, spoiling the conversation (or igniting a flame war).
  - infinity0 7y ago
    More and more often recently, I find downvoted comments that I thought are all perfectly useful and reasonable to the discussion. I in fact thought the downvotes were neither "useful" nor "contributing to the discussion". I would rather like to downvote the downvoters to reduce their karma and their power to perform these downvotes, but the only mechanic I have on HN to express my preference is to re-upvote the comment, which is not in fact its original intended purpose. Rather, I would like to ignore all downvotes made by particular downvoters because I believe their judgements are highly flawed, independent of the quality of the original comment that was downvoted. https://abstrusegoose.com/527 https://abstrusegoose.com/527 is highly relevant.
devit 7y ago
Currently the Linux kernel disables preemption inside spinlocks and interrupt handlers, and these code sections are not necessarily carefully written to be short and constant-time, so you can in theory get in a situation where all cores are running spinlock or interrupt handler code from low priority threads for arbitrarily long times, preventing higher priority realtime threads to run (which in practice means that whatever hardware you are controlling will be uncontrolled, and thus your self-driving car, rocket, plane or industrial machine might be destroyed). The PREEMPT_RT patch solves this by reimplementing all kernel spinlocks as mutexes with priority inheritance that are fully preemptible and all interrupt handlers as preemptable threads. The result is that if you have a bunch of real-time process/thread that do not make system calls, it's guaranteed that in a bounded amount time the highest priority set will be running. If you do however make system calls (or even if you cause page faults because you didn't call mlockall() and accessed non-mlocked memory), with the exception of some system calls that provide better guarantees, then you can still have kernel spinlock contention with other threads that may hold the same spinlock for an unbounded amount of time, so the system is more limited than dedicated real-time OSes that are careful about this.
- deleted 7y ago
  [deleted]

zdw 7y ago

I wasn't able to find documentation for using CIFS as / - is there a guide somewhere? What are the advantages of this as compared with NFS?

pkaye 7y ago
CIFS is I think the protocol used on Windows and SAMBA.
- jagger27 7y ago
  Yes, ish. CIFS is the protocol that came before SMB, but people still use the term to describe modern Windows SMB or Samba.
  - burfog 7y ago
    SMB was first. CIFS is a rebranding that happened when Microsoft was forced to release documentation for the protocol.
    - derefr 7y ago
      Yes, but CIFS was a rebranding of SMB1; successive versions of SMB have just been called SMB. So first there was SMB, and then CIFS, and then (and now) it's all been just SMB. The only ones still using the term "CIFS" at this point are the Linux/Samba folks.
      - burfog 7y ago
        It's a case of running the Common Internet File System on top of the Server Message Block protocol. SMB isn't just for filesystems. It is also used for printing, among other things. CIFS is the filesystem. Outside of Linux/Samba folks, neither term is popular. Users say "Windows share" or "shared drive" or "network folder" or something like that.
  - blattimwind 7y ago
    Don't see someone call SMB "modern" every day...