Linux 4.19 Preparing Better CPU Security Mitigations, New EROFS File-System (phoronix.com)

An anonymous reader writes: Linus Torvalds released on Sunday Linux 4.19-rc1 that he describes as a "fairly frustrating merge window" following the new features landing over the past two weeks. What does this "pretty big release" offer? Phoronix's Linux 4.19 feature overview sheds light on more Spectre CPU mitigations for x86/POWER/s390, the new EROFS read-only Android file-system, a Raspberry Pi voltage driver, ThinkPad calculator key support, an in-kernel GPS subsystem, the Google GASKET driver framework, virtual kernel mode-setting, Qualcomm Adreno 600 series support, and many other improvements.

Comments

Frankenkernel

[Anonymous Coward]

There is no way a single kernel should be doing all this shit.

Re:Frankenkernel

[Anonymous Coward]

Probably not, but until something huge happens that's specifically kernel-related and not CPU crap, well, to the moon!

Re:Frankenkernel

[Anonymous Coward]

Like my English teacher might have said: "When in doubt, put it in the kernel."

Re:Frankenkernel

[AHuxley]

Now with extra big systemd

Re: Frankenkernel

[Zero__Kelvin]

That's probably why a single kernel doesn't do all this shit. The source is there for all these features, but each kernel is customized with conditional compilation controlled by the .config file at build time.

Re: Frankenkernel

[Zero__Kelvin]

... has literally *nothing* to do with the kernel. There is *zero lines* of systemd code in the kernel. You can't even troll competently. Sad ... Bigly sad.

Re:Frankenkernel

[Shikaku]

You can actually compile what you don't want out of the kernel you know... ah nevermind, most of the kernel is just drivers anyway, and there's even USB support for the human body so it is really a frakenkernel.

Re: Frankenkernel

[Kjella]

That's probably why a single kernel doesn't do all this shit. The source is there for all these features, but each kernel is customized with conditional compilation controlled by the .config file at build time.

While that's true most will use their distro's precompiled kernel which obviously has most things enable to support all the possible use cases their customers have. I guess it works to keep experimental code in the tree but not in the default build, but once it's lifted to "production code" I think a lot of people will get it by default.

Re: Frankenkernel

[Zero__Kelvin]

That is not correct. The Linux kernel supports over 30 hardware architectures so it is impossible to build it with most options enabled. Furthermore many options are suboptions. With over 1000 choices, many of which are mutually exclusive there is literally no way to build a Linux kernel with "most options enabled." Finally, most drivers are built as modules, which technically aren't "enabled" they way you are using the term unless they are loaded at runtime. Since you never built a kernel from source in your life (or you would know this) it is best to remain silent and be thought the fool you are than to open your mouth and remove all doubt as you have done.

Re: Frankenkernel

[Anonymous Coward]

very well said. sadly most folks who use x86/x86-64 distros don't see the delineation as clearly as the embedded folks. these projects spend months patching linux drivers to a specific SoC/SoM and know precisely where the kernel stops - and their fallback is busybox for what most people recognize as the OS. Patching/customizing linux is not for the faint hearted (and I've come to hate their use of macros with some passion) but one of the sad side effects of (the usability of) Ubuntu is that we have a lot of linux "experts" who don't seem to know where the kernel actually stops. I sometimes with building your own linux kernel went more mainstream - would maybe polish some of the stuff more and teach folks what exactly the kernel does.

Re: Frankenkernel

[Anonymous Coward]

Each kernel. Read it again. Each kernel. Every distros "default kernel" is on of those "eaches".

Re: Frankenkernel

[funky_vibes]

Message passing was stupid and therefore ultimately failed. Let's move on.

Re:Frankenkernel

[Anonymous Coward]

A "voltage driver" might be huge. I'm a firmware engineer and have never heard of such a thing. So it must be huge.

Re: Frankenkernel

[Anonymous Coward]

"There is no way a single kernel should be doing all this shit."

Linux is going to grow itself into oblivion. Sooner or later, a fork of Linux has to occur.

"There is *zero lines* of systemd code in the kernel."

Even if SystemD lies just outside kernel space, it can now dip into the kernel to track you. Moreover, kernel space GPS makes it easier for the Chinese frankengovernment to track its citizens.

"but each kernel is customized with conditional compilation controlled by the .config file at build time."

But that's precisely what turns monolithic Linux into a frankenkernel, and Linus has been pushed aside to let this happen. In his day, it wasn't a frankenkernel, by any means.

"I sometimes with building your own linux kernel went more mainstream - would maybe polish some of the stuff more and teach folks what exactly the kernel does."

There's a typo in this sentence. Problem is, there needs to be a definitive, authoritative ".config" hacker's guide to help us understand what to touch, and what not to touch, for even the most basic Intel configuration. We get your point and don't disagree with your premise. Our problem is that we have long lost the beauty of the kernel, since it moved away from being single architecture. If there were 30 separate kernels for 30 separate architectures, it would keep Linus and his crew very busy, syncing all the kernels.

The complexity of Linux demonstrates where the cathedral and the bazaar thesis falls apart. Linux purports to be a community effort, but it has become an insider's game, and we in the community can only traipse along, trying to catch up with where it is headed as a monolithic kernel.

Perhaps this discussion about the complexity of Linux leads us directly into a discussion of whether a microkernel architecture would reduce the complexity of Linux. We know where Linus stands on this issue, so microkernel proponents are going to have to deliver a working example to convince us of a microkernel's viability.

Linus once told an audience that he judged a kernel developer by whether he could easily read his or her code. Well, I have news for you, Linus. The whole kernel is unreadable with all its layers of built in macros.

Re: Frankenkernel

[Anonymous Coward]

I was a joke, dumbass. You make Trump look smart by comparison.

Re: Frankenkernel

[phantomfive]

And now everyone builds their own custom message queue to do IPC. Message passing isn't a bad idea, it's a bad idea to use it for *everything*

Re:Frankenkernel

[sad_]

well, computers aren't simple things anymore, should a single cpu do all the things it does today? compared to the old days (oh my) where it was possible for one person to know all the ins & outs of a whole machine, or where the circuit diagrams were included in the manual. impossible today.

that said, the linux kernel isn't as bad as you make it out to be. a lot of stuff is left to handle specifically in userland, i think it is even the preference of Linus to move anything out of the kernel that is not really needed. there have been several big examples of this in the last 27 years when things that were initially part of the kernel were moved out.

Re: Frankenkernel

[Megol]

Yes you were & are.

Re: Frankenkernel

[Anonymous Coward]

https://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Hwmon-Linux-4.19

Re:Frankenkernel

[Anonymous Coward]

Now with more vitamin D than ever!

Re: Frankenkernel

[Anonymous Coward]

"There is no way a single kernel should be doing all this shit."

Linux is going to grow itself into oblivion. Sooner or later, a fork of Linux has to occur.

"There is *zero lines* of systemd code in the kernel."

Even if SystemD lies just outside kernel space, it can now dip into the kernel to track you. Moreover, kernel space GPS makes it easier for the Chinese frankengovernment to track its citizens.

"but each kernel is customized with conditional compilation controlled by the .config file at build time."

But that's precisely what turns monolithic Linux into a frankenkernel, and Linus has been pushed aside to let this happen. In his day, it wasn't a frankenkernel, by any means.

"I sometimes with building your own linux kernel went more mainstream - would maybe polish some of the stuff more and teach folks what exactly the kernel does."

There's a typo in this sentence. Problem is, there needs to be a definitive, authoritative ".config" hacker's guide to help us understand what to touch, and what not to touch, for even the most basic Intel configuration. We get your point and don't disagree with your premise. Our problem is that we have long lost the beauty of the kernel, since it moved away from being single architecture. If there were 30 separate kernels for 30 separate architectures, it would keep Linus and his crew very busy, syncing all the kernels.

The complexity of Linux demonstrates where the cathedral and the bazaar thesis breaks down. Linux purports to be a community effort, but it has become an insider's game, and we in the community can only traipse along, trying to catch up with where it is headed as a monolithic kernel.

Perhaps this discussion about the complexity of Linux leads us directly into a discussion of whether a microkernel architecture would reduce the complexity of Linux. We know where Linus stands on this issue, so microkernel proponents are going to have to deliver a working example to convince us of a microkernel's viability.

Linus once told an audience that he judged a kernel developer by whether he could easily read his or her code. Well, I have news for you, Linus. The whole kernel is unreadable with all its layers of built in macros.

Re:Frankenkernel

[DontBeAMoran]

Now with 150% more recycled pixels!

Re: Frankenkernel

[funky_vibes]

Everyone builds their own message queue because there aren't any known good message queue libs, only standards which don't really fit anyone but pretending to be usable for everything.
The best message queue libs I've seen have always been internal company projects, and even they weren't generic enough, and were regularly bypassed for higher efficiency.

It's the same as any other protocol. We need very generic tools to properly explain specific protocols for specific tasks.
And the part of protocol design where we fail most is layering and extension. When underlying protocols have even minor design flaws, it makes layering impractical and generates yet another protocol to add to the confusion.

I believe in dividing up software (into processes) as much as possible in userspace, but the interfaces need to be simultaneously human- and machine-accessible for the division to carry any reasonable cost/benefit-ratio since it's already hard to keep people from baking things together when they are in a hurry.

Re: Frankenkernel

[phantomfive]

I had similar thoughts, but I'm not really sure why there aren't any good message queue libs. It doesn't make sense.

Re:Frankenkernel

[Anonymous Coward]

Frankenkernel was not the name of the kernel, it was the name of the person who wrote the kernel.

Kernel Security Code

[Anonymous Coward]

I got a preview of the security Code:

if (cpu_vendor == intel) {
                    disable_L1_cache();
                    disable_L2_cache();
                    disable_L3_cache();
                    disable_instr_cache();
                    disable_data_cache();
                    disable_branch_prediction();
                    disable_hyperthreading();
                    if (ultra_secure_mode == true) {
                                      for (i=1;i=num_cores-1;i++) {
                                                    disable_core(i);
                                      }
                    }
}

one can expect a heavy performance penalty, but the power consumption should go way down, so we have that going for us.

Re: Kernel Security Code

[Anonymous Coward]

Actually its liable to overheat after it gets caught in that infinite loop in ultra secure mode.

Re: Kernel Security Code

[Anonymous Coward]

Thermal managment will halt the system

Re: Kernel Security Code

[Zero__Kelvin]

Wow ... How did you get such a preview? Did you git pull it out of your ass?

Re: Kernel Security Code

[Anonymous Coward]

No, they got it from your ass, next to your mom's fist.

Re: Kernel Security Code

[Zero__Kelvin]

Not sure who is more of a dirty little cunt ... You or her? Nope, it is definitely you.

Re: Kernel Security Code

[Anonymous Coward]

Not sure who is more of a dirty little cunt ... You or her? Nope, it is definitely you.

Yes but you, sir, are a nígger. There is no coming back from that.

Re: Kernel Security Code

[Zero__Kelvin]

No sir. I'm a smart brotha. I'm a blues man. I'm some really chill brothas nigga. But you da brotha for whom the word you used incorrectly was invented.

Re: Kernel Security Code

[Anonymous Coward]

Unfortunately, that was disabled in the previous microcode security patch.

Re: Kernel Security Code

[Anonymous Coward]

No sir. I'm a smart brotha. I'm a blues man. I'm some really chill brothas nigga. But you da brotha for whom the word you used incorrectly was invented.

Tell ya what. When blacks start fathering their own children (currently just over 1 out of 10 - pathetic), stop committing violent crimes far in excess of their percentage of the population, and value education as much as they currently value thug life/street crime, everywhere they are found even in natinos that had no slavery and no equivalent to Jim Crow, then there will no longer be any reason to use that word ever.

Re: Kernel Security Code

[Zero__Kelvin]

The topic was niggrrs like you. What do you think you will gain by bringing skin color into the conversation?

Re: Kernel Security Code

[Anonymous Coward]

You know your mom's a dirty little cunt with quite a fetid cunt. Yet you keep licking it. No wonder your dad left you. Oh, don't forget to take your herpes medication. And your neighbors are complaining about the smell again.

Re: Kernel Security Code

[Anonymous Coward]

The topic was niggrrs like you. What do you think you will gain by bringing skin color into the conversation?

So, not bright enough to evade the lameness filter properly then? Nígger. That's how you do it.

I'm not entirely sure what you think the word means but it refers to those of African descent. You see, the Spanish have this word "niger" which means "black" as in the color. When their colonialists found black people the term "nígger" later derived from their word for "black". You with me so far? Good.

What you call "skin color", I call pattern recognition. These are people who were around thousands upon thousands of years before the white man, yet when the white man figured out astronomy and navigation and logistics and built ships that could traverse much of the globe, and discovered the black man, those blacks lacked things like the wheel, writing, and agriculture. If they were truly equal, then the fact they existed thousands of years earlier would mean they would have had an advanced space program at about the time Captain Cook started sailing. This has not been the case. Today in the US their males are about 6-7% of the population yet account for over 50% of all solved murders, primarily killnig each other. Draw your own conclusions from the available data. Or close your mind to facts.

Re: Kernel Security Code

[Zero__Kelvin]

So you took what I wrote and tried to make it your own? Good (blow) job!

Re:Kernel Security Code

[Anonymous Coward]

You missed the bit where Intel applied this "patch" for all CPUs, even those unaffected by their exploits.

Re: Kernel Security Code

[Anonymous Coward]

If white people didn't molest children and kill kids and all the rest, you'd have a point. Because your statistics are flawed, but you can't deny white people are criminals, murderers, perverts molesters and dumb thugs too.

It's a product of poverty and lack of education, resources for advancement. Where those things overlap crimes you describe occur frequently in all races. You're a fool, it's silly that someone so dumb fancies themselves better than.

Re: Kernel Security Code

[Anonymous Coward]

It's not an infinite loop

Re: Kernel Security Code

[grimr]

Yes it is. The test condition is assignment and not a comparison.

If AC intended for it to be == then it would work fine until it ran on a single core machine. Then the loop would run 4 billion times.

So that comparison should be =

Re: Kernel Security Code

[grimr]

Gah, slashdot munged my less than or equal operator and turned it into =

I suspect now that's what happened to AC's code.

Re: Kernel Security Code

[Anonymous Coward]

Whites were in poverty too. Everyone started out that way when you look at the big picture.

Re: Kernel Security Code

[Anonymous Coward]

LOL. What happen during the dark ages? The world was shit you say? People routinely, robbed, and killed their neighbors.

Re:Kernel Security Code

[BrookSmith]

I understand that Intel are currently employing engineers from Volkswagen to implement code to detect if the CPU is being performance tested to re-enable all the caches so they can achieve a positive test result.

USA has the strongest Linux Colonels ever!

[Anonymous Coward]

It's a good thing USA Linux doesn't rely on socialist open source software or the untrustworthy labor of immigrants or foreigners. I just can't figure out where to send the check so they send me the CD in the mail?

Re:USA has the strongest Linux Colonels ever!

[jfdavis668]

You can order disks here: https://www.osdisc.com/

Way to improve CPU security:

[Gravis Zero]

Only buy AMD.

Re:Way to improve CPU security:

[AHuxley]

We can talk about the benchmark results too.

Re: Way to improve CPU security:

[Anonymous Coward]

AMD has never had a security bug or any bug for that matter

Re:Way to improve CPU security:

[Anonymous Coward]

AMD smokes Intel, everyone knows that. More lanes = faster pipes = more tubes = speedier contractor corruption adding onto your Alaska mansion with taxpayer monies. Everyone knows this already since Ted Stevens.

Re:Way to improve CPU security:

[Anonymous Coward]

Considered that on my most recent laptop, but I wanted a decent performance:price ratio.

Re:Way to improve CPU security:

[Anonymous Coward]

AMD smokes Intel, everyone knows that.

Funny how everyone knows that now. If I wrote that little over a year ago I'd get downvoted into oblivion, and I've been using an AMD AM3 / AM3+ based PC for most of the last decade. How many Intel CPU socket changes happened during that time?

Re:Way to improve CPU security:

[Anonymous Coward]

Umm no. Hopefully something like RISC-V develops into a common platform where everyone knows what the hell the CPU is doing and there are no dirty tricks going on.

We need to get away from this x86 garbage, we've needed to get away from it for decades...

Re:Way to improve CPU security:

[Anonymous Coward]

> Only buy AMD.

I've had a space heater before, thank you very much. I prefer a computer under my desk, even if it might have some theoretical exploits that only apply under some very specific circumstances that aren't very likely to be the case as a home PC user.

Re: Way to improve CPU security:

[rahvin112]

Uh, no.

mediatek USB wireless AC

[Anonymous Coward]

It appears that it might support my wireless AC. If so, finally I will be able to use 5ghz and 802.11ac in Linux with my USB adapter!

Re:mediatek USB wireless AC

[Anonymous Coward]

It appears that it might support my wireless AC. If so, finally I will be able to use 5ghz and 802.11ac in Linux with my USB adapter!

If you shove the USB adapter up your own rancid ass hole it gets better reception. I think maybe the whole body turns into an antenna. Plus it feels real good too. Win-win! Just use superglue or some twine to make sure the USB cable is SECURELY fastened to the adapter, that way the cable leads out of your asshole and you can connect it to your computer. Then when you want to remove it, you can pull it out like an ass-tampon. See, you gotta think these things through.

Re:mediatek USB wireless AC

[Anonymous Coward]

Why do you hate yourself so much?

Re:mediatek USB wireless AC

[Anonymous Coward]

Re "Plus it feels real good too" and "you can pull it out like an ass-tampon", I will have to defer to your expertise on these. And I thought all you guys in the Russian troll farm did was trolling. Now I see you have your own recreational pursuits.

New EROFS

[hcs_$reboot]

New ERO file-system, not mentioned in TFA, what can that be...

Re:New EROFS

[Tailhook]

It's a read-only file system from Huawei, intended to be an improvement on over existing read-only file systems for Android devices. Yes, this is the same Huawei that makes phone you can't (couldn't, may not be able to in the future...?) take into a US military facility, FWIW.

Re:New EROFS

[Anonymous Coward]

EROFS is the complementary file system to /dev/null.

Re:New EROFS

[Anonymous Coward]

New japan specific filesystem. It has a number of specialty provisions, such as supporting the new regnal name for timestamps, and some niche embedded industry extensions...

Re:New EROFS

[thegarbz]

Yes, this is the same Huawei that makes phone you can't (couldn't, may not be able to in the future...?) take into a US military facility, FWIW.

It's worth nothing. Sudden panic banning Chinese equipment without any actionable intelligence is bad enough, but conflating the company with some open source code that has been independently reviewed and mainlined in the kernel is worth even less.

Re:New EROFS

[Tailhook]

Sudden panic banning

The US congress has been warning US corporations to avoid Huawei and ZTE since 2012. You reveal your own ignorance if you actually believe current events are something sudden or surprising.

Australia has joined the US in banning Huawei from infrastructure work. They recognize this company is simply a commercial arm of the PLA and are wisely keeping it out of critical infrastructure.

This is the sort of naiveté people in the US use to have about Russia.

Re:New EROFS

[thegarbz]

The US congress has been warning US corporations to avoid Huawei and ZTE since 2012. . You reveal your own ignorance if you actually believe current events are something sudden or surprising.

LOL WUT? If you think what was happening in 2012 is any way remotely comparable to the actions of the past 4 months I have a bridge to sell you, one with a government warning label.

Australia has joined the US in banning Huawei from infrastructure work.

Yep. The 51st State of America expressing its independence once again. Interestingly you note yourself here that the ban is new, the multinational effort is new, yet you accuse me of ignorance for realising that a fucking lot has changed in the past few months?

They recognize this company is simply a commercial arm of the PLA

They recognise the USA has told people without ever producing a shred of evidence. But sure let's all buy nice secure definitely not backdoored Cisco gear instead right?

This is the sort of naiveté people in the US use to have about Russia.

To channel my inner 5 year old: "Stop talking about yourself"

Everyone at Google should be murdered.

[Anonymous Coward]

It should be illegal for Intel, or Google or Microsoft to put their disgusting shit into the Linuz kernel. Android is a stupid Java toy piece of shit and Google just wants to make it easier for themselves by stuffing their patches into the mainline, instead of dealing with changes in their own copy. This should be illegal. If you are some corporate piece of shit that believes in keeping your stuff closed source while invading everyone's privacy for profit, then you should be barred from contributing anything to Linux, on the grounds you are a filthy, scheming over-valued shitbag and your "contribution" is just a way to entrench your stupid product where it is not wanted, and does not belong.

Fuck Intel.

Support for laptops that only have USB-C

[cerberusss]

The summary left out a pretty important point from the article, in my opinion:

The USB Type-C display mode alternate driver was merged to the mainline kernel for stepping up the DP Type-C support, but more work on integrating with the DRM drivers is still being tackled.

So what this means, is that you have a dongle or monitor cable with USB-C on one end, and DisplayPort on the other end.

This is important, because I expect to see new laptops coming out, that only have USB-C/Thunderbolt 3. The obvious existing ones are from Apple, but I expect that more laptops will come out with no other ports except USB-C/Thunderbolt 3.

Re:Support for laptops that only have USB-C

[Anonymous Coward]

Well some have the switching between USB-only mode / Displayport mode done in hardware and work even if not supported by linux, afaik.

Re:Support for laptops that only have USB-C

[Anonymous Coward]

Dell XPS 13 is another.

Re:Support for laptops that only have USB-C

[rahvin112]

Not likely outside apple. Most other manufacturers will keep at least one A port because they aren't stupid enough to assume everyone has a wireless mouse and all mouse transmitters are USB-A. They might have a single Halo product that mimics Apple but the majority will include A ports.

Re:Support for laptops that only have USB-C

[Anonymous Coward]

You can get a decent wireless mouse for $20.

numbnuts

Thinkpad calculator key

[Anonymous Coward]

As someone who has had a ThinkPad of some sort or another for 10+ years running Linux... what is the calculator key supposed to do?

Re:Thinkpad calculator key

[wed128]

Depends on what you've mapped it to...

EROFS

[azrael29a]

By looking at the name of EROFS I thought we will finally have a dedicated porn filesystem. So disappointed.

Er, GPS in-kernel, WTF?

[Anonymous Coward]

Why the fuck isn't GPS a userland process? What business does it have being in-kernel?

People still only look st lines of code

[jd]

Linux has been modular for decades, so you only include what you use. So if you don't use the filesystem or the patch, you don't install the filesystem or patch.

Interactions should only be with the local subsystem, so a hundred modules of a hundred thousand makes no difference. You're still only looking at core functions (kernel core functions plus local API). The subsystem takes care of security, etc.

With kernel threads, non-interacting code blocks don't need to risk blocking each other.

Because context switches are the things that kill performance, reducing context switches by having all of a module in the kernel rather than half in is a good approach. Exokernels (where only essential code is ring 0) are only faster if you're not having to make a lot of calls across. Microkernels are generally slower than monolithic, modular or eco.

At this point, the cost of mitigating the Intel bugs is more than the cost of recalling the chips or the cost of using formal methods to prevent such bugs arising to begin with. This shows why doing it right is better than doing it cheaply. (Something I've said for the past 30 years.)

Frankly, I'm not impressed with the improvements of the last few releases. Zero copy was introduced both with Von Jacobson Channels and the RDMA Consortium, again many decades ago. It should be standard for all I/O subsystems. I'm also still waiting for the plugable scheduler, as no individual scheduler is right for all systems.

And if people really want a lighter kernel, then have the filesystem and network subsystems standalone. If you can upload them on to a sufficiently advanced disk controer/network card respectively, you can offload all that work and use message passing to mask where it's running. Decentralization. Reduces the consequence of bad CPUs, you can't interfere with code that isn't running on it, and might improve performance as the CPU isn't hogged.

Some parts of the kernel may be buggy or vulnerable to regression. If they can be rewritten in Verified C, or so that they can be praised with Why3, you can start to develop theorems that will establish if the code is behaving as you'd expect.

Lost track of whether SGI's kernel debugger was fully integrated with the mainline. If not, why not and can someone please bring it up to date and get it looked at properly?

Same with Web10g, the network profiling system. We could do a lot with that if it were, ummm, used by people and not hiding in obscurity.

What's the story with badmem? Now that cheapo space missions are going to be common, Linux needs to support the ability to be used in a slowly degrading computer.

Re:Er, GPS in-kernel, WTF?

[Anonymous Coward]

It is a driver for GPS devices.

All it does is provide the communications with the device, and control the device.

GPS subsystem

[anonieuweling]

What's the deal with the GPS subsystem that was mentioned for 4.19?
What can this subsystem do and why does it have to be in the kernel?

And yes, I buy AMD where I can.

Re:GPS subsystem

[Anonymous Coward]

It provides a character device and presents a standard interface to various GPS devices. This way you don't need to give software direct access to the USB device or whatever other interface the hardware requires. Makes life a lot easier for a software developer who needs to read a GPS device if they don't need to support 2398234 different ways of getting location info.

Re:GPS subsystem

[fisted]

If only there was a userland program like gpsd to unify GPS providers into a standard format output stream. Oh wait, there is...

Re:GPS subsystem

[Anonymous Coward]

If only there was a userland program like gpsd to unify GPS providers into a standard format output stream

It's not so much about the format, as it is how you need to speak to the GPS device.

You still end up needing to give gpsd excessive permissions for what it needs to do for various devices. Often you'll need to give access for gpsd to access the USB bus directly via libusb. With this driver, gpsd would only need to open up a character device, rather than having intimate knowledge of how each GPS device needs to be interfaced with.

There are many embedded devices that can only be accessed over GPIO pins and/or some other architecture specific method and as a result a lot of non-standard device drivers have popped up to present some sort of character device to userspace. This is one of the primary reasons for this sort of driver, where its impossible for a userspace implementation to speak to the device without giving direct i/o memory access.

It's the same sort of difference between the old XFree86 servers that needed full root access and permission to /dev/mem to function correctly vs modern versions that use the kernel provided DRI/KMS interface.

Isn't that one of the main points of an operating system kernel, to provide standard APIs for varied hardware so that user programs don't need to fully understand all of the low level details of the device?

USB: DP vs PD

[Anonymous Coward]

The summary left out a pretty important point from the article, in my opinion:

The USB Type-C display mode alternate driver was merged to the mainline kernel for stepping up the DP Type-C support, but more work on integrating with the DRM drivers is still being tackled.

Slight confusing:

* DP = DisplayPort: https://www.displayport.org/displayport-over-usb-c/

But if you transpose them:

* PD = PowerDelivery: http://www.usb.org/developers/powerdelivery/

Of course you can connect a display using DP to a laptop, and also have the screen have PD to charge the battery.

Ero-FS

[Anonymous Coward]

Ero-Manga, Ero-Game, Ero-Anime, Ero-FS!

EROFS?

[Anonymous Coward]

As in erotica?

I guess it's in line with the rest of Linux/UNIX history of sexual fetish/fantasies: fsck, gimp, stdin, stdout.