Announcement

Collapse
No announcement yet.

A Run Down Of VT Switching On Linux

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

  • #11
    Originally posted by Ericg View Post
    Moving the VT's from kernelspace to userspace is about removing hacky, inefficient, complicated spaghetti code in the kernel.
    Isn't it more like separating and replacing code rather than removing, considering that kernel doesn't break the interfaces to userspace?

    Originally posted by duby229
    My question is, will this be a requirement for running the linux kernel? If it's optional and I can still run the linux kernel and switch terminals without it, then I'm fine with it.
    No, so you have nothing to worry about.

    Comment


    • #12
      Originally posted by Teho View Post
      Isn't it more like separating and replacing code rather than removing, considering that kernel doesn't break the interfaces to userspace?
      Fair enough, it will probably be hidden by a config switch for many years. HOPEFULLY it will eventually be removed after its fairly certain that its no longer used.
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #13
        Originally posted by dvdhrm View Post
        A pure revoke() system-call doesn't help. In fact, the revoke() syscall would be papering over kernel problems. If you have better ideas than the one proposed, please let us know. But nobody so far could come up with one. Besides, I like the logind idea, so why exactly do you not like it?
        I object to pointless abstraction layers. They are a scourge of modern computing. Insert quote by Linus on this topic here.

        What exactly does a needless daemon add, that extending VTs and input handling in kernel would not? Beyond wasting resources?

        Comment


        • #14
          Originally posted by curaga View Post
          I object to pointless abstraction layers. They are a scourge of modern computing. Insert quote by Linus on this topic here.

          What exactly does a needless daemon add, that extending VTs and input handling in kernel would not? Beyond wasting resources?
          Did you read the posts linked to in the article? Because they explain all that. VTs are as old and as difficult to deal with as the X server due to them not being designed to do anything like what they're asked to do today. Getting rid of them gets rid of a very poor, extremely limited IPC layer. And the "needless daemon" is already running on most Linux distributions, including Ubuntu, and its design fits this purpose pretty much exactly.

          As for what it adds, it's enhanced stability and no more resource conflicts. As I said on the blog there, the current system is much like the Real Mode of CPUs, it's a horrible idea based on trust that all the software has no bugs and is written sanely. The new system is like Protected Mode, making sure that even if a program misbehaves/malfunctions, it won't be able to deadlock the whole PC. In addition, the new system does away with artificial limitations, which allows such things as multiple sessions on a single seat (currently that's only possible if there is only a single seat).

          Also, VTs have no reason to be in the kernel, because as the name implies, they're virtual. They're not actual devices. They ought to be created and deleted by the userland.
          Last edited by GreatEmerald; 26 August 2013, 11:00 AM.

          Comment


          • #15
            This sounds like a solution in search of a problem and users that actually care. On the other hand, it could break things horribly especially for those failsafe situations.

            it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

            It seems like a perfect microsoftism.

            Comment


            • #16
              Originally posted by Rallos Zek View Post
              This sounds like a solution in search of a problem and users that actually care. On the other hand, it could break things horribly especially for those failsafe situations.

              it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

              It seems like a perfect microsoftism.
              What. Again, did you even read the posts in the article? Did you read my last post? What you're saying is pretty much the same as claiming that Wayland is a solution in search of a problem, because X.org happens to still somehow work. And yes, users do care about stability, security and opening multiple sessions on multiple seats.

              Comment


              • #17
                Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

                Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

                With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

                This wannabe Lennart Poettering trying to make the console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possible.

                Comment


                • #18
                  Originally posted by Rallos Zek View Post
                  Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

                  Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

                  With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

                  This wannabe Lennart Poettering trying to make the console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possible.
                  The console already depends upon working userspace... Invalid point is invalid. If your X Server freezes, you can't switch to a console. If the kernel isn't compiled with Sys-Rq AND its not actived in sysctl.conf, you can't even Sys-Rq out. If something is hogging the CPU to the point where almost nothing can happen... you might get to console, but the console can't call /bin/login. And even if /bin/login IS called and you get a login screen, you probably won't get /bin/{bash.sh,zsh,csh} running anyway.

                  The very fact that you say "Messy opaque system much like windows" and "complexity in userspace" tells EVERYONE on these boards that you don't actually know what you're talking about and have only heard information from equally biased third parties, who probably selectively pulled out quotes to fit their own bias. Either you're trolling on purpose-- in which case you'll be reported, or you'll showing your ignorance for everyone to see and only embarrassing yourself. I its the latter I HIGHLY suggest you start reading code and documentation FOR YOURSELF and TALK to the developers YOURSELF and you'll realize how much of a mess we are in NOW and these "complexities" you call them are the result because we half-assed systems for so long, called them "good enough" and convinced ourselves they were "good enough" because the alternative was facing how much of a piss-poor position we were actually in.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    Originally posted by Rallos Zek View Post
                    Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

                    Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

                    With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

                    This wannabe Lennart Poettering trying to make the console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possible.
                    Yea, this shows that you didn't read a single one of the posts linked in the article. They explain that the current system is the cause of not being able to access self-reliant recovery options, and the new system introduces them. With the current system if your X server hangs where it doesn't release the resources, you can't switch out of it, because it is the only thing that has access to your input (and output) devices. The improvements in logind make it so that logind is capable of forcefully disconnecting the resources from such a hung X server and giving them to a newly spawned session.

                    Comment


                    • #20
                      Originally posted by GreatEmerald View Post
                      Did you read the posts linked to in the article? Because they explain all that. VTs are as old and as difficult to deal with as the X server due to them not being designed to do anything like what they're asked to do today. Getting rid of them gets rid of a very poor, extremely limited IPC layer. And the "needless daemon" is already running on most Linux distributions, including Ubuntu, and its design fits this purpose pretty much exactly.

                      As for what it adds, it's enhanced stability and no more resource conflicts. As I said on the blog there, the current system is much like the Real Mode of CPUs, it's a horrible idea based on trust that all the software has no bugs and is written sanely. The new system is like Protected Mode, making sure that even if a program misbehaves/malfunctions, it won't be able to deadlock the whole PC. In addition, the new system does away with artificial limitations, which allows such things as multiple sessions on a single seat (currently that's only possible if there is only a single seat).

                      Also, VTs have no reason to be in the kernel, because as the name implies, they're virtual. They're not actual devices. They ought to be created and deleted by the userland.
                      Yes, I did read his blog posts. Did you read my post?

                      VTs are as old and as difficult to deal with as the X server due to them not being designed to do anything like what they're asked to do today.
                      Originally posted by curaga
                      ...that extending VTs...
                      And the "needless daemon" is already running on most Linux distributions, including Ubuntu, and its design fits this purpose pretty much exactly.
                      No, it's not. If you read the blog posts, the work to make it do its job is just now being done. So why would any existing distro deploy it, when it doesn't do its job fully yet? It may be in the development Ubuntu version, but not in any released one.

                      which allows such things as multiple sessions on a single seat (currently that's only possible if there is only a single seat).
                      Originally posted by curaga
                      ...that extending VTs and input handling in kernel...
                      Also, VTs have no reason to be in the kernel, because as the name implies, they're virtual. They're not actual devices. They ought to be created and deleted by the userland.
                      They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?

                      Comment

                      Working...
                      X