clean up kernel_{read,write} & friends v2

[Linus Torvalds]

On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight at aculab.com> wrote:
>
> A wide monitor is for looking at lots of files.

Not necessarily.

Excessive line breaks are BAD. They cause real and every-day problems.

They cause problems for things like "grep" both in the patterns and in
the output, since grep (and a lot of other very basic unix utilities)
is fundamentally line-based.

So the fact is, many of us have long long since skipped the whole
"80-column terminal" model, for the same reason that we have many more
lines than 25 lines visible at a time.

And honestly, I don't want to see patches that make the kernel reading
experience worse for me and likely for the vast majority of people,
based on the argument that some odd people have small terminal
windows.

If you or Christoph have 80 character lines, you'll get possibly ugly
wrapped output. Tough. That's _your_ choice. Your hardware limitations
shouldn't be a pain for the rest of us.

Longer lines are fundamentally useful. My monitor is not only a lot
wider than it is tall, my fonts are universally narrower than they are
tall. Long lines are natural.

When I tile my terminal windows on my display, I can have 6 terminals
visible at one time, and that's because I have them three wide. And I
could still fit 80% of a fourth one side-by-side.

And guess what? That's with my default "100x50" terminal window (go to
your gnome terminal settings, you'll find that the 80x25 thing is just
an initial default that you can change), not with some 80x25 one. And
that's with a font that has anti-aliasing and isn't some pixelated
mess.

And most of my terminals actually end up being dragged wider and
taller than that. I checked, and my main one is 142x76 characters
right now, because it turns out that wider (and taller) terminals are
useful not just for source code.

Have you looked at "ps ax" output lately? Or used "top"? Or done "git
diff --stat" or any number of things where it turns out that 80x25 is
really really limiting, and is simply NO LONGER RELEVANT to most of
us.

So no. I do not care about somebody with a 80x25 terminal window
getting line wrapping.

For exactly the same reason I find it completely irrelevant if
somebody says that their kernel compile takes 10 hours because they
are doing kernel development on a Raspberry PI with 4GB of RAM.

People with restrictive hardware shouldn't make it more inconvenient
for people who have better resources. Yes, we'll accommodate things to
within reasonable limits. But no, 80-column terminals in 2020 isn't
"reasonable" any more as far as I'm concerned. People commonly used
132-column terminals even back in the 80's, for chrissake, don't try
to make 80 columns some immovable standard.

If you choose to use a 80-column terminal, you can live with the line
wrapping. It's just that simple.

And longer lines are simply useful. Part of that is that we aren't
programming in the 80's any more, and our source code is fundamentally
wider as a result.

Yes, local iteration variables are still called 'i', because more
context just isn't helpful for some anonymous counter. Being concise
is still a good thing, and overly verbose names are not inherently
better.

But still - it's entirely reasonable to have variable names that are
10-15 characters and it makes the code more legible. Writing things
out instead of using abbreviations etc.

And yes, we do use wide tabs, because that makes indentation something
you can visually see in the structure at a glance and on a
whole-function basis, rather than something you have to try to
visually "line up" things for or count spaces.

So we have lots of fairly fundamental issues that fairly easily make
for longer lines in many circumstances.

And yes, we do line breaks at some point. But there really isn't any
reason to make that point be 80 columns any more.

                  Linus