Announcement

Collapse
No announcement yet.

The Linux Kernel Console Is Being Killed Off

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

  • #31
    Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
    I can't get any numbers on size of a static binary though:
    Code:
    $ ./autogen.sh 
    autoreconf2.50: Entering directory `.'
    autoreconf2.50: configure.ac: not using Gettext
    autoreconf2.50: running: aclocal --force --warnings=all -I m4
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: configure.ac: tracing
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: libtoolize --copy --force
    libtoolize: putting auxiliary files in `.'.
    libtoolize: copying file `./ltmain.sh'
    libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
    libtoolize: copying file `m4/libtool.m4'
    libtoolize: copying file `m4/ltoptions.m4'
    libtoolize: copying file `m4/ltsugar.m4'
    libtoolize: copying file `m4/ltversion.m4'
    libtoolize: copying file `m4/lt~obsolete.m4'
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
    automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
    autoreconf2.50: Leaving directory `.'
    checking for a BSD-compatible install... /usr/bin/install -c
    checking whether build environment is sane... yes
    checking for a thread-safe mkdir -p... /bin/mkdir -p
    checking for gawk... gawk
    checking whether make sets $(MAKE)... yes
    checking whether to disable maintainer-specific portions of Makefiles... yes
    checking for style of include used by make... GNU
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables... 
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc accepts -g... yes
    checking for gcc option to accept ISO C89... none needed
    checking dependency style of gcc... gcc3
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /bin/grep
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking minix/config.h usability... no
    checking minix/config.h presence... no
    checking for minix/config.h... no
    checking whether it is safe to define __EXTENSIONS__... yes
    checking build system type... i686-pc-linux-gnu
    checking host system type... i686-pc-linux-gnu
    checking for a sed that does not truncate output... /bin/sed
    checking for fgrep... /bin/grep -F
    checking for ld used by gcc... /usr/bin/ld
    checking if the linker (/usr/bin/ld) is GNU ld... yes
    checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
    checking the name lister (/usr/bin/nm -B) interface... BSD nm
    checking whether ln -s works... yes
    checking the maximum length of command line arguments... 1572864
    checking whether the shell understands some XSI constructs... yes
    checking whether the shell understands "+="... yes
    checking for /usr/bin/ld option to reload object files... -r
    checking for objdump... objdump
    checking how to recognize dependent libraries... pass_all
    checking for ar... ar
    checking for strip... strip
    checking for ranlib... ranlib
    checking command to parse /usr/bin/nm -B output from gcc object... ok
    checking for dlfcn.h... yes
    checking for objdir... .libs
    checking if gcc supports -fno-rtti -fno-exceptions... no
    checking for gcc option to produce PIC... -fPIC -DPIC
    checking if gcc PIC flag -fPIC -DPIC works... yes
    checking if gcc static flag -static works... yes
    checking if gcc supports -c -o file.o... yes
    checking if gcc supports -c -o file.o... (cached) yes
    checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
    checking whether -lc should be explicitly linked in... no
    checking dynamic linker characteristics... GNU/Linux ld.so
    checking how to hardcode library paths into programs... immediate
    checking whether stripping libraries is possible... yes
    checking if libtool supports shared libraries... yes
    checking whether to build shared libraries... yes
    checking whether to build static libraries... yes
    checking for gcc option to accept ISO C99... -std=gnu99
    checking for pkg-config... /usr/bin/pkg-config
    checking pkg-config is at least version 0.9.0... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
    checking whether to build documentation... yes
    checking for doxygen... /usr/bin/doxygen
    checking for inline... inline
    checking for typeof syntax and keyword spelling... typeof
    checking for flex... flex
    checking lex output file root... lex.yy
    checking lex library... -lfl
    checking whether yytext is a pointer... yes
    checking for bison... bison -y
    checking for bison... /usr/bin/bison
    checking for strcasecmp... yes
    checking for strncasecmp... yes
    checking for eaccess... yes
    checking for euidaccess... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'
    Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

    Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
    Somehow this doesn't look promising.
    Last edited by Ibidem; 02-08-2013, 09:37 PM.

    Comment


    • #32
      Originally posted by Ibidem View Post
      Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
      I can't get any numbers on size of a static binary though:
      Code:
      $ ./autogen.sh 
      autoreconf2.50: Entering directory `.'
      autoreconf2.50: configure.ac: not using Gettext
      autoreconf2.50: running: aclocal --force --warnings=all -I m4
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      autoreconf2.50: configure.ac: tracing
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      autoreconf2.50: running: libtoolize --copy --force
      libtoolize: putting auxiliary files in `.'.
      libtoolize: copying file `./ltmain.sh'
      libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
      libtoolize: copying file `m4/libtool.m4'
      libtoolize: copying file `m4/ltoptions.m4'
      libtoolize: copying file `m4/ltsugar.m4'
      libtoolize: copying file `m4/ltversion.m4'
      libtoolize: copying file `m4/lt~obsolete.m4'
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
      configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
      Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
      automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
      autoreconf2.50: Leaving directory `.'
      checking for a BSD-compatible install... /usr/bin/install -c
      checking whether build environment is sane... yes
      checking for a thread-safe mkdir -p... /bin/mkdir -p
      checking for gawk... gawk
      checking whether make sets $(MAKE)... yes
      checking whether to disable maintainer-specific portions of Makefiles... yes
      checking for style of include used by make... GNU
      checking for gcc... gcc
      checking whether the C compiler works... yes
      checking for C compiler default output file name... a.out
      checking for suffix of executables... 
      checking whether we are cross compiling... no
      checking for suffix of object files... o
      checking whether we are using the GNU C compiler... yes
      checking whether gcc accepts -g... yes
      checking for gcc option to accept ISO C89... none needed
      checking dependency style of gcc... gcc3
      checking how to run the C preprocessor... gcc -E
      checking for grep that handles long lines and -e... /bin/grep
      checking for egrep... /bin/grep -E
      checking for ANSI C header files... yes
      checking for sys/types.h... yes
      checking for sys/stat.h... yes
      checking for stdlib.h... yes
      checking for string.h... yes
      checking for memory.h... yes
      checking for strings.h... yes
      checking for inttypes.h... yes
      checking for stdint.h... yes
      checking for unistd.h... yes
      checking minix/config.h usability... no
      checking minix/config.h presence... no
      checking for minix/config.h... no
      checking whether it is safe to define __EXTENSIONS__... yes
      checking build system type... i686-pc-linux-gnu
      checking host system type... i686-pc-linux-gnu
      checking for a sed that does not truncate output... /bin/sed
      checking for fgrep... /bin/grep -F
      checking for ld used by gcc... /usr/bin/ld
      checking if the linker (/usr/bin/ld) is GNU ld... yes
      checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
      checking the name lister (/usr/bin/nm -B) interface... BSD nm
      checking whether ln -s works... yes
      checking the maximum length of command line arguments... 1572864
      checking whether the shell understands some XSI constructs... yes
      checking whether the shell understands "+="... yes
      checking for /usr/bin/ld option to reload object files... -r
      checking for objdump... objdump
      checking how to recognize dependent libraries... pass_all
      checking for ar... ar
      checking for strip... strip
      checking for ranlib... ranlib
      checking command to parse /usr/bin/nm -B output from gcc object... ok
      checking for dlfcn.h... yes
      checking for objdir... .libs
      checking if gcc supports -fno-rtti -fno-exceptions... no
      checking for gcc option to produce PIC... -fPIC -DPIC
      checking if gcc PIC flag -fPIC -DPIC works... yes
      checking if gcc static flag -static works... yes
      checking if gcc supports -c -o file.o... yes
      checking if gcc supports -c -o file.o... (cached) yes
      checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
      checking whether -lc should be explicitly linked in... no
      checking dynamic linker characteristics... GNU/Linux ld.so
      checking how to hardcode library paths into programs... immediate
      checking whether stripping libraries is possible... yes
      checking if libtool supports shared libraries... yes
      checking whether to build shared libraries... yes
      checking whether to build static libraries... yes
      checking for gcc option to accept ISO C99... -std=gnu99
      checking for pkg-config... /usr/bin/pkg-config
      checking pkg-config is at least version 0.9.0... yes
      /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
      checking whether to build documentation... yes
      checking for doxygen... /usr/bin/doxygen
      checking for inline... inline
      checking for typeof syntax and keyword spelling... typeof
      checking for flex... flex
      checking lex output file root... lex.yy
      checking lex library... -lfl
      checking whether yytext is a pointer... yes
      checking for bison... bison -y
      checking for bison... /usr/bin/bison
      checking for strcasecmp... yes
      checking for strncasecmp... yes
      checking for eaccess... yes
      checking for euidaccess... yes
      /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
      /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'
      Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

      Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
      Somehow this doesn't look promising.
      You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)

      Comment


      • #33
        huu, it was extremely fast and smooth output relative the old console. Nice looking printing is good

        Comment


        • #34
          Originally posted by Ericg View Post
          You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)
          Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

          I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
          I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

          That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
          Fetching a proper tarball worked, but there's more issues:
          KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
          Patch that, and try...oops, --with-fonts=8x16 isn't supported.
          Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
          And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
          OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

          All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
          If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!

          Comment


          • #35
            Originally posted by Ibidem View Post
            Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

            I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
            I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

            That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
            Fetching a proper tarball worked, but there's more issues:
            KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
            Patch that, and try...oops, --with-fonts=8x16 isn't supported.
            Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
            And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
            OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

            All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
            If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!
            I do have a response but since we have the developer here in the forums I won't derail things and just let him respond since its a choice of dependency issue. Dvdhrm, response?

            Comment


            • #36
              A huge bless to the CJK community

              Originally posted by asdx
              I hope this project takes off. Please ignore all the dirty neckbeards crying over this project.

              When can we start using this project? Or when it will be implemented in distros like archlinux, etc?
              Now. Archlinux already packages it. Link: https://www.archlinux.org/packages/c...x86_64/kmscon/

              I have been using KMSCON as my main console since last December. The experience has been very smooth.

              People in the west might not realize this, but this project is a huge blessing to the entire CJK community.
              The good old linux-console is practically useless to us except as the emergency console, 'cause it has no
              capability of displaying CJK characters. There's been various efforts within the CJK community, but none has
              worked out well. KMSCON is the first proper solution to this problem.

              Comment


              • #37
                Originally posted by Ibidem View Post
                Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

                I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
                I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

                That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
                Fetching a proper tarball worked, but there's more issues:
                KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
                Patch that, and try...oops, --with-fonts=8x16 isn't supported.
                Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
                And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
                OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

                All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
                If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!
                Why didn't you try out kmscon-6? If you use git-builds, please don't complain if the documentation isn't up to date. I usually update documentation before doing a release. 8x16 font is now built-in so you no longer need to pass it to --with-fonts. libudev-172 is required (as mentioned in the README) because it introduced udev_device_has_tag().

                udev is currently used in one single file (uterm_monitor.c). The TODO list includes an item "make udev optional". I haven't done this yet, because no-one showed me good reasons to do so and I am still working on more important stuff. Please note, kmscon is still experimental. I haven't advertised it anywhere, so please consider it experimental.

                And please, if you have issues with it, open a bug-report, write an email or contact me via any other medium. But don't complain in public forums and expect the developers to find this and fix stuff.
                For instance, why didn't you open a bug-report that autoconf 2.67 is enough?


                Regarding the problem with plymouth:
                You cannot use plymouth together with any other application that uses graphics devices. Why do you want to use plymouth --show-splash from the console? It simply acquires all input/video devices and shows the splash screen. This doesn't work if another application (like xserver or kmscon) currently uses the devices.
                I don't understand why anyone would want that? Could you elaborate a bit more?

                Regards
                David

                Comment


                • #38
                  Originally posted by dvdhrm View Post
                  The TODO list includes an item "make udev optional". I haven't done this yet, because no-one showed me good reasons to do so and I am still working on more important stuff.
                  good reason for making udev optional:
                  udev is not a core component required to run a linux system. but the linux console is.
                  and udev is not a de-facto standard either, because even for systems that require hot plug functionality, there exist alternatives, namely mdev, as i mentioned on page 3 of this thread.

                  distro builders like me that build lightweight distros will be pissed if they need to install libudev even if they dont need hot plug functionality or use busybox' mdev instead, forcing them to waste precious memory resources (my distro runs even on devices with only 2MB ram), storage resources and build time etc for this entirely unneeded stuff.

                  keep in mind that linux has much more use cases than just the typical ubuntu desktop system.

                  Originally posted by dvdhrm View Post
                  Please note, kmscon is still experimental. I haven't advertised it anywhere, so please consider it experimental.
                  as long as it is only experimental, removing the good old linux console in favor of it is just ... insane.

                  Comment


                  • #39
                    Originally posted by dvdhrm View Post
                    Regarding the problem with plymouth:
                    You cannot use plymouth together with any other application that uses graphics devices. Why do you want to use plymouth --show-splash from the console? It simply acquires all input/video devices and shows the splash screen. This doesn't work if another application (like xserver or kmscon) currently uses the devices.
                    I don't understand why anyone would want that? Could you elaborate a bit more?

                    Regards
                    David
                    It was for TESTING plymouth, I had just installed plymouth on my Arch box and was testing different splash screens. I just happened to run
                    Code:
                    plymouthd && plymouth --show-splash
                    from a KMSCON console. While I agree that you don't want to manually run plymouth and that no one would do that normally, I do feel like it is a bug that kmscon and plymouth --show-splash clash if you do want to one day have KMSCON being the full-blown replacement for the kernel VT's since you do sometimes want to test plymouth and it works just fine under the normal VT's.

                    Comment


                    • #40
                      Originally posted by asdx
                      I hope this project takes off. Please ignore all the dirty neckbeards crying over this project.

                      When can we start using this project? Or when it will be implemented in distros like archlinux, etc?
                      Arch has in their repositories. What I can see it work today, at lest in the limited use I tried it in.

                      Comment


                      • #41
                        Originally posted by asdx
                        So how do I replace the current Linux console with kmscon?
                        To just test it all you have to do is install it, switch a VT and run 'kmscon', to kill it switch to a seperate VT and kill kmscon. Setting it as the default VT handle is beyond my knowledge, maybe David can answer that one.

                        Comment


                        • #42
                          Originally posted by asdx
                          So how do I replace the current Linux console with kmscon?
                          Try
                          ln -s /usr/lib/systemd/system/kmscon@.service /etc/systemd/system/autovt@.service
                          systemctl enable kmscon@.service
                          assuming you're using systemd

                          Comment


                          • #43
                            OK, just over 1 MB static and stripped.
                            Thanks for the recommendation to try release 6, dvdrhm.
                            It does take some work to circumvent libtool's attempts to link everything dynamically.
                            And...
                            Code:
                            -rwxr-xr-x 1 idunham idunham 1606899 Feb 11 20:45 kmscon
                            -rwxr-xr-x 1 idunham idunham 1033328 Feb 11 20:46 kmscon_strip
                            -rwxr-xr-x 1 idunham idunham  482480 Feb 11 20:57 kmscon-test
                            That last one is what happens when I link it static with musl.
                            Apparently it ~works even if I stop udev.

                            I'm assuming "init=/bin/bash" and similar are not supported use cases? Because the only way that could work with VT emulation in userspace is if kmscon supported executing a specified command like xterm -e (for example, init=/sbin/kmscon -e /bin/bash )

                            Also, what does kmscon do if the xkb data is inaccessible?
                            OK, it fails to run.
                            That's ~3 MB more.

                            Comment


                            • #44
                              "man this code in the kernel is so hard to understand, and it's just useless bloat. let's move it to userland" where it becomes even more fragile, unmaintainable, and bloated.

                              sigh...

                              Sometimes, when you find the code you're looking at is "too hard to understand" it means that you're too stupid to muck with it, and should leave it TF alone and go do something else with your time.

                              Comment


                              • #45
                                Originally posted by highlandsun View Post
                                Sometimes, when you find the code you're looking at is "too hard to understand" it means that you're too stupid to muck with it, and should leave it TF alone and go do something else with your time.
                                Beyond uncalled for, even the maintainer of the VT subsystem has called the code spaghetti, a mess, broken by design, and about every other phrasing you can use for shitty code. Also moving it out of the kernel is a nice idea as far as maintainability is concerned because in Userspace you can break whatever the hell you want if you need to refactor-- in the kernel once its there...its there until Linus dies.

                                Comment

                                Working...
                                X