Announcement

Collapse
No announcement yet.

SERDEV "Serial Device Bus" Added To Linux 4.11 Kernel

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

  • SERDEV "Serial Device Bus" Added To Linux 4.11 Kernel

    Phoronix: SERDEV "Serial Device Bus" Added To Linux 4.11 Kernel

    The TTY/serial patches were mailed in earlier this week by Greg KH for the Linux 4.11 kernel merge window. Normally this isn't a pull request with much interest from us as it's generally not too interesting, but this time around it introduces a new bus...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is TTY still on schedule to be dropped from the kernel?

    Why doesn't anyone implement a TTY/console/terminal/VT as a Wayland compositor that runs in userspace?
    Setup a OpenGL context that renders text and use libinput to get input and then run a user-specified shell such as Bash.
    Last edited by uid313; 24 February 2017, 08:12 AM.

    Comment


    • #3
      nothing like breaking good old serial support in 2017 ;-) guess the next time I boot a SPARC or PowerPC serial is dead until bisecting :-/

      Comment


      • #4
        Originally posted by uid313 View Post
        Is TTY still on schedule to be dropped from the kernel?

        Why doesn't anyone implement a TTY/console/terminal/VT as a Wayland compositor that runs in userspace?
        Setup a OpenGL context that renders text and use libinput to get input and then run a user-specified shell such as Bash.
        the day text console is dropped from kernel is the day i switch to windows or BSD.

        Comment


        • #5
          Originally posted by uid313 View Post
          Is TTY still on schedule to be dropped from the kernel?

          Why doesn't anyone implement a TTY/console/terminal/VT as a Wayland compositor that runs in userspace?
          Setup a OpenGL context that renders text and use libinput to get input and then run a user-specified shell such as Bash.
          I am also waiting for the death of CONFIG_VT. Just way to much complexity in the kernel.

          Comment


          • #6
            Originally posted by cj.wijtmans View Post

            the day text console is dropped from kernel is the day i switch to windows or BSD.
            To be perfectly honest, I feel the same way and would seriously consider switching my day-to-day computing machine to FreeBSD in that situation. The whole point of the text console is that it's more or less unbreakable. I already managed to produce an un-reproduceable "can't talk to systemd because the D-Bus daemon is non-responsive" situation on one of my deployment-testing VMs that required me to hard-reset it to get things back to normal.

            (If you want to try reproducing it, it's the VirtualBox variant of the "bento/debian-8.6" vagrant VM and the problem happened when I experimentally switched from `cron` to `systemd-cron` and then back again to see if it would reduce the memory footprint appreciably... thankfully, it's for testing ansible deployments, so, in the worst case scenario, all I'd have to do is "vagrant destroy && vagrant up && ansible-playbook ...".)

            It's annoying enough for the el-cheapo OpenVZ VPSes I use that systemd was clearly not written for resource efficiency. (eg. On my dinky little VPSes, /sbin/init is the heaviest process on the system before I set up some kind of dynamic web app, having at least twice the RSS of runners-up like exim4 and nginx... not to mention that journald treats its own memory-limiting settings as passing suggestions unless I set it to Storage=none and install inetutils-syslogd to forward to.)

            (journald+inetutils-syslogd with Storage=none sits steady at 1/5th of the peak journald alone insists on climbing to with any other storage mode, even under the heaviest test loads I could throw at them.)
            Last edited by ssokolow; 24 February 2017, 09:55 AM.

            Comment


            • #7
              Originally posted by ssokolow View Post

              To be perfectly honest, I feel the same way and would seriously consider switching my day-to-day computing machine to FreeBSD in that situation. The whole point of the text console is that it's more or less unbreakable. I already managed to produce an un-reproduceable "can't talk to systemd because the D-Bus daemon is non-responsive" situation on one of my deployment-testing VMs that required me to hard-reset it to get things back to normal.
              Exactly. Its something you can rely on especially since systemd more or less is anti KISS. If you have such problems with the text console then why not use windows.

              Comment


              • #8
                Originally posted by cj.wijtmans View Post
                Exactly. Its something you can rely on especially since systemd more or less is anti KISS. If you have such problems with the text console then why not use windows.
                Except I have had many experiences with the graphics drivers (both sides) going bung and text console not working...

                Comment


                • #9
                  Originally posted by cj.wijtmans View Post

                  the day text console is dropped from kernel is the day i switch to windows or BSD.
                  This is ports related not terminal related. In other words new ways to handle serially interfaced hardware. I don't see a problem really.

                  Comment


                  • #10
                    News says: "new way to operate devices attached to UART (serial) ports on a SoC"

                    People's reaction: "if they remove serial I'm switching to HURD, Systemd is bad"

                    Comment

                    Working...
                    X