Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft open-sources ThreadX

theregister.com

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Microsoft open-sources ThreadX

#111

Post by aleph_minus_one »

pjmlp wrote: post #71
joezydeco wrote: post #5

This was "Azure RTOS", bought by Microsoft in haste after Amazon acquired FreeRTOS. Bill Lamie left to start PX5 and work on a new lightweight embedded RTOS and took most of the talent with him. If Microsoft is doing this, they're pretty much walking away from their roadmap for Azure RTOS and IoT nodes along those lines. I call it a win, ThreadX had a lot more ecosystem behind it than FreeRTOS ever did. And it does r…

Yeah, it feels like getting rid of it. I never understood why they got it, when they already had Azure Sphere OS. At least they are open sourcing it, instead of leaving it in some digital vault.

> I never understood why they got it, when they already had Azure Sphere OS.

Azure Sphere OS is based on Linux, thus needs much more powerful hardware than ThreadX.

Re: Microsoft open-sources ThreadX

#112

Post by sillywalk »

jylam wrote: post #91
joezydeco wrote: post #9

Earlier quoted context omitted.

I understand the notion here that opening up ThreadX will start to allow visibility into VideoCore, since ThreadX runs the thing. But an RTOS/scheduler is only a miniscule part of a GPU and since Broadcom never opens up anything, I believe it's a false hope. Opening up any GPU code, from any maker, invites patent lawsuits from competitors. And then the injunctions start flying.

Having worked (very) closely on GPU firmwares and drivers, I always find it funny that it is still something so closely guarded and protected. Honestly there isn't much to it. That's fairly regular code, not like futuristic algorithms. You won't find any novel rasterizing code or ways to order your commands or whatever, 99% of the interesting work is done by the GPU. You'll find basic or vaguely clever code to order…

I'm old enough to remember the Open Graphics Project, to create at least initially an FPGA graphics card, and use the money to make an ASIC.

It died ~2011

https://en.wikipedia.org/wiki/Open_Graphics_Project

Re: Microsoft open-sources ThreadX

#113

Post by wyldfire »

cinntaile wrote: post #45
joezydeco wrote: post #5

This was "Azure RTOS", bought by Microsoft in haste after Amazon acquired FreeRTOS. Bill Lamie left to start PX5 and work on a new lightweight embedded RTOS and took most of the talent with him. If Microsoft is doing this, they're pretty much walking away from their roadmap for Azure RTOS and IoT nodes along those lines. I call it a win, ThreadX had a lot more ecosystem behind it than FreeRTOS ever did. And it does r…

It's an acquisition from 2017 but do you happen to know why Amazon bought FreeRTOS?

Amazon is heavily marketing AWS ro automotive R&D teams. They want them to run their software on Graviton nodes for near-hw performance. And they have virtio-everything interfaces for you to use so your core functionality can be tested in AWS and you have some kind of hypervisor to partition and/or abstract the real HW interfaces.

A "software defined vehicle" [1].

Those R&D teams spend a small fortune on devboards with each new generation and only use them for ~a couple years or so. So renting time on AWS is appealing because it's not depreciating capital and because they can be more flexible in how they adjust spending to suit development cycle phases where they need more/fewer concurrent units.

Having freertos allows them to have credible experts in the space their customers are working in, and they can make design changes to freertos to suit this SDV concept.

[1] https://aws.amazon.com/automotive/software-defined-vehicle/

Re: Microsoft open-sources ThreadX

#114

Post by twisteriffic »

LispSporks22 wrote: post #81
freedomben wrote: post #64

This is indeed a major deal, and having the Eclipse Foundation shepherd it is wonderful. Microsoft deserves praise and even adulation for this, but time will tell how well supported the project is. They have a good track record so I'm very optimistic, but this is going to require a lot of ongoing support. That shouldn't be and isn't on Microsoft alone now, but they may have to shoulder a larger burden while getting t…

Are they dumping it on Eclipse and waving bye-bye or are they sticking around to develop it further? Many projects seem to be ditched by corporations and kind of orphaned in Eclipse and Apache

A _lot_ of Microsoft's open source projects are basically ghost towns. EF core and the SQL server driver appear to be maybe a handful of people, and there is a disturbing amount of "the only person who understood this is gone so we can't fix it.". Get into some of the more esoteric projects and you're lucky if there's someone dropping in to accept a PR once a year.

I'm assuming that every dev ends up consumed by endless rewrites of the Azure client libraries.

Re: Microsoft open-sources ThreadX

#115

Post by Szpadel »

wyldfire wrote: post #113
cinntaile wrote: post #45

Earlier quoted context omitted.

It's an acquisition from 2017 but do you happen to know why Amazon bought FreeRTOS?

Amazon is heavily marketing AWS ro automotive R&D teams. They want them to run their software on Graviton nodes for near-hw performance. And they have virtio-everything interfaces for you to use so your core functionality can be tested in AWS and you have some kind of hypervisor to partition and/or abstract the real HW interfaces. A "software defined vehicle" [1]. Those R&D teams spend a small fortune on devboards wi…

that's really cool idea, but for such r&d local hardware/vm seems to be more ergonomic for attaching debugger and if you have to create such abstractions anyways, I'm not sure if dev board with second CPU or FPGA for hw emulation wouldn't be better way to handle it, as this would allow you to reuse same boats between generations

Re: Microsoft open-sources ThreadX

#117

Post by MarkSweep »

robot wrote: post #116

It is not open source. The source code is open but with an evaluation, i.e. proprietary license: https://github.com/azure-rtos/threadx/blob/master/LICENSE.tx...

With the odd provision that you can only ship the software on certain devices:

https://github.com/azure-rtos/threadx/blob/master/LICENSED-H...

Re: Microsoft open-sources ThreadX

#118

Post by westurner »

uxp8u61q wrote: post #63
SanjayMehta wrote: post #35

Earlier quoted context omitted.

The IME ran on Minix. https://itsfoss.com/fact-intel-minix-case/

You've got that reversed. IME runs MINIX now, it used to run on ThreadX.

Linux (1991) started as a fork of MINIX (1987) by Tanenbaum.

History of Linux: https://en.wikipedia.org/wiki/History_of_Linux

MINIX: https://en.wikipedia.org/wiki/Minix

Redox OS: https://en.wikipedia.org/wiki/Redox_(operating_system) :

> Redox is a Unix-like microkernel operating system written in the programming language Rust, which has a focus on safety, stability, and performance. [4][5][6] Redox aims to be secure, usable, and free.

Re: Microsoft open-sources ThreadX

#119

Post by andy_threos_io »

My view that, this code is nice, however IMO there are several ways to make it more portable, and programer friendly, specially the ported assembly code part.

Example.

In file threadx-master/ports/cortex_a7/gnu/src/tx_thread_schedule.S

in this code

    /* Increment the run count for this thread.  */

    LDR     r2, [r0, #4]                    // Pickup run counter
    LDR     r3, [r0, #24]                   // Pickup time-slice for this thread
    ADD     r2, r2, #1                      // Increment thread run-counter
    STR     r2, [r0, #4]                    // Store the new run counter
the indexes to the data structures are really hard to modify, so you can't make modifications to the structures easy, the C structures and the assembly code indexes must be in sync, or the system will crash. And there are literally 100s of files with assembly indexes in the code.

But it can be made it easier, with another layer and macro preprocessing. So make a header one for the assembly and one for the C code, and define the struct with the macro. The assembly code can be compiled with C preprocessor, so the macros will work.

This way the C and the ASM stay sync. Only drawback, that the struct must be defined with this macros. But this is only for the structures that are used both in assembly and C or higher level.

Anyway if the indexes in the assembly code would be macros, that would be also much easier to modify.

Re: Microsoft open-sources ThreadX

#120

Post by AlotOfReading »

demondemidi wrote: post #105
AlotOfReading wrote: post #92

Earlier quoted context omitted.

I've also led the process at multiple companies. It's a big enough space that there's definitely room for different experiences, even within the same companies. That said, I'm surprised you've never encountered issues with people e.g. not understanding how serious UB is vs other types of issues in C-family languages. That's fairly universal even among developers from what I've seen.

I think you might be confusing software standards with functional safety standards. They are related, but one is required by the other. FuSa from my role has been predominantly architecture and process. Developers do need to follow coding and documentation guidelines. If they are fighting that then there are bigger problems with leadership.

It's one of the [major] hazards you have to deal with in FuSa software systems, so I'd say it goes under both. So much of 26262-6 is about limiting the scope of those those sorts of issues that just waving it away as a prerequisite ends up being neither practical nor realistic.
Post reply on HN