Torvalds suggests poison and sabotage for ARM SoC designers Help us out here amateur psychologists: Linus Torvalds has just unleashed his second shouty rant in as many days. Do we need to worry, or is the moon in a particular phase that makes this kind of thing more likely? Has Portland's water supply taken a turn for the worse? Or are we simply seeing a frustrated middle aged man …
The only thing Linus is good at is preaching to the choir. Enemies of open source rejoice at his lack of professionalism. So Linus, you make the open source community look good by running your mouth. Keep up the excellent work dude! Maybe someone could possibly puncture the brake-lines on your car and put a little surprise in your coffee.
At least you can make a point without losing your cool, unlike Linus. Thumbs up!
Well, let's put it this way … I can understand why he makes the outbursts he does. I don't necessarily agree 100% but I do understand why those things are said.
A few years ago I was working with Jacques Electronics helping develop their video intercom system.
They had chosen a rather capable system-on-module (SoM) as the core of their product, and had picked the components that built up their devices. They had initially two form-factors of video intercom: a desk-top unit with 800x480 resistive touch-screen, the monitor station; and an in-wall mounted unit with a 320x240 pixel screen and capacitive keypad, the entrance station. Later, they added a headless version of the entrance station that just had a LED and mechanical keypad (and then yet a fourth, that used a piezo push-button in place of the mechanical keypad — for out-door help points and in prisons).
We initially had fun and games getting the audio codec and system-on-chip (SoC) to communicate. The audio codec was made by TI, the SoC by FreeScale. After explaining our situation to the TI sales rep, TI did provide us with an ALSA driver, after forcing representatives to sign an NDA (red flag IMO), but then on inspecting the code we saw comments stating the driver was only licensed for use on a TI OMAP processor, and for kernel 2.6.18. Utterly useless.
I wound up porting the SoM's support code over to kernel 2.6.36 (they were running 2.6.28) where there was at least support for the SoC's I²S bus, getting the audio codec working, then back-porting the whole ALSA tree back to kernel 2.6.28. All because TI wanted to play silly proprietary games.
The next challenge came that management wanted to be able to plug the SoM, loaded up with OS, into any of the devices and have it auto-detect what device it was plugged into. This is challenging because SPI and I²C both are non-discoverable: you basically have to know what's there by default.
I wound up kludging it by making use of an on-main-board I²C EEPROM which could carry information on what sort of board it was, making the kernel look for a specific kernel command-line parameter, then hacking RedBoot to pass this special command line parameter depending on the content of the EEPROM. Ugly, no way in hell upstream would accept the patch, but it worked.
Now this is with just one SoC. Linus and other kernel devs have to face harmonising a single kernel tree with the myriad of SoC's out there. All with varying amounts of documentation, of differing quality. Quite often, the manufacturers are not forthcoming on how their particular SoC operates, and it all lends itself to an experience akin to herding cats. There's no "let's work together on this and try to come up with a clean architecture that will work well for all our products", it's more "let's focus on our own product line and to hell with anything else Linux runs on".
The ultimate loser in this is the end user, which in this context, is the company trying to develop a product for their customers. Rather than being able to select a SoC and other hardware based on specifications and cost, they have to factor in device-family-specific kernel trees that may be lagging behind mainline by years, may be incompatible with other kernel trees, and each carry with it its own unique set of bugs.
So yes, I might not be the sort to jump up and down and scream abuse, or hurl furniture around, but I can well understand it when someone who's trying to get a kernel that everyone can use, gets thrown into such anarchy.
"The ultimate loser in this is the end user, which in this context, is the company trying to develop a product for their customers. Rather than being able to select a SoC and other hardware based on specifications and cost, they have to factor in device-family-specific kernel trees that may be lagging behind mainline by years, may be incompatible with other kernel trees, and each carry with it its own unique set of bugs."
"Users" can vote with their wallets. Instead of going for $CHEAPEST device which then requiers a shedload of manhours every time there's a variation, go for the one which is fully documented, etc.
Requirements for NDAs seem to fall away rapdily in the face of "Oh well, we'll just switch to XYZ competing manufacturer".
"The only thing Linus is good at is preaching to the choir"
Well that and being a Hell of an engineer and hard worker.
I used to argue with Eadon all the time - a complete PITA who did more damage to the image of Open Source than any detractor of Open Source usually managed. Linus? I have nothing but respect for. Don't confuse an opinionated bigot with a very talented person who has a sense of humour and speaks his mind.
Having an opinion on a subject is fine: "Non discoverable buses are right PITA". He's involved in writing an operating system kernel and this issue is a problem for him (and all other operating system authors)
Threatening violence on people: "I hope [they] all die in some incredibly painful accident", not so clever.
Personally I think his comments could be equally applied to the person who dreamed up the use of the title "Human Resources" over "Personnel". The manner in which, with one simple renaming, they remove the implied caring about those who work for you as real people to one which, ironically, removes the humanity.
"Social Mobility" is another....
Linus is being far too polite. Transistor counts on these SOC's are in the multiple of billions. Reserving a couple of thousand so the software can detect the hardware it is running on and configure itself appropriately is a no-brainer.
It makes everyone's life so much easier. It means the kernel writers can take on the burden of identifying and configuring the hardware, so the manufacturers, retailers and what not can just have one firmware image that runs on everything - just like Microsoft and the Linux distributions do. "How to find the board revision number of your hardware" becomes unnecessary.
Arsehole doesn't begin to describe the mentality of these hardware designers. Absolute arrogant pricks. Paris because they are high maintenance, just like her.
For suppliers of SoC based equipment, configuring Linux is often the norm to avoid the kernel having loads of unwanted code. For example on a basic MP3 player the complete communication stack is unwanted as there is no externally connected communication interface (even if the SoC has one).
Generic kernels are far larger than custom tailored kernels -for example on the netbook that I am using at the moment the generic kernel image on disk is 3.9MP - and includes support for IP6, DECnet, Packet radio, Bluetooth, EISA bus, multiple CPU types and many other options that will never be used.
For the manufacturer of small SoC based systems, having the devices discoverable provides no benefit and will hinder if there are devices on the SoC whose use is not wanted.
Having something like a CONFIG_MTK6589T file that configures all the devices on a MTK6589T SoC would seem to be the best approach. (The MTK6589T SoC is the chip in my current phone - a THL W8S.)
>Having something like a CONFIG_MTK6589T file that configures all the devices on
>a MTK6589T SoC would seem to be the best approach. (The MTK6589T SoC is the
>chip in my current phone - a THL W8S.)
That's what the old pre device tree setup did.. it used the machine number passed in from the bootloader in R1 and ran the board file for the selected device.
The problem with that is that you end up with tons of machine numbers, tons of mostly similar but slightly different board files etc etc.. The DT stuff is meant to make this stuff a bit more sane. A port for an ARM machine now is just an extension DTS file that builds on top of the SoC's DT.
I was meaning a file that was used during the Linux kernel build so that the kernel had only the correct device drivers - not a boot time or run time configuration of a generic kernel (a CONFIG_MTK6589T make file).
Correctly done you would have a generic make file that included a type file (e.g CONFIG_PHONE or CONFIG_TABLET or CONFIG_EMBEDDED etc), the SoC make file and the specific board file (if any) for additional devices or to disable not connected SoC devices. The CONFIG_xxx files would include lower level files so for example the CONFIG_MTK6589 file would include CONFIG_QUAD_CORE_ARM_A7 minimising the amount of duplicated configuration information. This results in smaller kernels with fewer bugs as errors in code that is not included does not have any effect on the kernel.
Read up on what DT actually does... if your totally static compile time configuration (which is what the old system basically is in most cases as most kernels only support 1 machine id) would actually work then there wouldn't be all of this effort to get DT working.
>This results in smaller kernels with fewer bugs as errors in code
>that is not included does not have any effect on the kernel.
Testing a lots of different kernel configurations is actually very important to find bugs with interactions between different parts of the kernel ... that's why you can produce kernels with random configs.
Would that be the Gordon Ramsay who is a multi-millionaire, whose own resaurants are consistently voted among the ten best in the world, who consistently turns around failing enterprises and makes them critical and commercial successes, and who keeps being awarded Michelin stars that recognise his outstanding skills and talents?
Or were you thinking of some other foul-mouth Gordan Ramsey who should not be used as a role model?
> Being good at something doesn't make you a role model.
Yes it does. Everyone is a role model if someone looks up to them.
Whether or not they are a "good" role model depends entirely on your personal perspective which is just as flawed as everyone else's.
From my point of view this behaviour is really puerile.
From mine, your posting is puerile, Linus is able to make comments on the kernel mailing list that aren't PC because he has the respect of the audience he's addressing. They know what he means. He doesn't need to kowtow to dumb conventions that might govern most business discussions, any more than you don't need to worry about being all PC when you're chatting to your mates down the pub.
"The post is required, and must contain letters."
Yep; see, the idea is that you put the message itself there, not in the f*****g title (even if it *is* something as insubstantial and redundant as "absolutely agree with Linus"; frankly, if you can't even be bothered explaining why you agree, it probably wasn't worth posting).
"Who gives a rat's ass about what "human resources managers" try to think about?"
Unfortunately, those who work at the companies that employ them.
HR "managers" in too many firms have power and authority (to hire and fire) well beyond their ability to understand the roles they hiring and firing for.
"HR "managers" in too many firms have power and authority (to hire and fire) well beyond their ability to understand the roles they hiring and firing for."
And once they've truely clusterfucked the organisations they get a nice golden handshake.
I know of one outfit where one HR manager nearly caused a general strike and another (female, with a political agenda) decided women werent being paid well enough, so launched a company-wide review process which left large numbers of staff traumatised and half the female staff in a worse position than they'd been previously.
They are under constant pressure to slap out new designs as soon as possible, they have the reduce the power consumption as much as possible, they have the keep the area of the die as small as possible, and in general SoC's are vastly more complicated (not in transistor count) than, for example, basic x86 chips (due to all the added HW blocks for graphics, cameras, networking etc)
All of these go against what Torvalds wants (and his wants are fair enough), but the designers are only doing what they are asked to do by the market.
We are not talking x86 chips here with a long dev cycle, we are talking devices that need to be designed, simulated, taped out, built, tested, redesigned etc in only a couple of years.
I agree with his arguments, less so with his phraseology. SoC designers are well down my list of people I'd like to see trip over their shoelaces.
What it needs is an agreed-upon standard for SoCs to have a bit of mask-ROM accessible that enumerates device IDs, a bit like PCI or USB have, so that an OS can read it and know that it's got an ACME type-2 SPI controller at base address X, an ACME type 4 NAND flash controller at base address Y, etc. A given SoC manufacturer normally re-uses its peripheral IP, so it shouldn't be that hard to achieve.
So, start of ROM has eight bytes to declare number of peripheral descriptors and a chip ID (which could be a short-cut to know what's coming next) and then eight bytes per peripheral to give it an ID and base address offset. A more flexible scheme would take more space but may be preferable for future-proofing.
>What it needs is an agreed-upon standard for SoCs to
>have a bit of mask-ROM accessible that enumerates device IDs,
What about devices that aren't part of the SoC but baked onto the board? How do you enumerate those?
>got an ACME type-2 SPI controller at base address X,
What about the SPI devices connected to that controller than need to be configured to make the board work?
>an ACME type 4 NAND flash controller at base address Y, etc.
What about the configuration of the NAND attached to the controller, what about the NAND partition table?
>A given SoC manufacturer normally re-uses its peripheral IP, so it shouldn't be that hard to achieve.
But it would be worthless. The vendor, chip model etc are already burned into the silicon, adding another location that describes the SoC is pointless.
>So, start of ROM
Or just have the bootloader load a binary into memory or attach a binary to the end of the kernel image that describes the particulars of the machine that the kernel is booting on... come to think of it.. that's what DeviceTree does. Almost as if it was intended to solve this very problem!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
