Rasp Pi model 3 WiFi

I think there should be a bounty to get WiFi working on the model 3 Pi. Linux seems to have cracked this so it should be a simple matter to do it for RISC OS as well.

A WiFi module could be softloaded under RISC OS using the code developed for Linux? Then it wouldn’t matter if it was GPL for example, as it would not be part of the OS.

I don’t think WiFi is a simple task. There are a few layers necessary. You need something which can glue between the hardware and the Internet module, with whatever abstractions for different hardware. Then you need a configuration API for things like joining networks.

A key Linux component is this https://wireless.wiki.kernel.org/en/developers/documentation/mac80211

Might be worth reading up on the NetBSD implementation?

If the code has been written for Linux, why don’t we just port it to RISC OS as a module? Unlike some other rom components which need static linking, WiFi can be softloadable (the signal may not be there on startup) and thus the GPL issue is harmless.

One RISC OS programmer recently mentioned to me that he’d discussed the problem with another programmer who reckoned the sensible approach would be:
“to re-port the FreeBSD Internet stack, not just because it would contain drivers for common WiFi chips and the mass of cryptographic stuff, but because the old FreeBSD stack lacks fundamental concepts like being able switch networks without a reboot which people take for granted with WiFi.

“The majority of the new RISC OS work would be user interface related – things like allowing people to choose which network to connect to by name, enter passwords, a signal strength meter, and (since the underlying
stack would be IPv6 “for free”) updating all the network configuration dialogue boxes to permit IPv6 addresses and netmasks."

How much work this is I do not know. Maybe it is time for a bounty?

Erm… ‘If the code has been written for Linux, why don’t we just port it to RISC OS as a module?’. I think this may be a slight oversimplification! :)

Updating the entire network stack sounds like a good plan regardless. The origins are from an old version of NetBSD, I believe.

I did think that basic WiFi management functions could be covered with star commands to begin with. I wouldn’t necessarily expect a fancy UI for joining public access points etc. Not straight away at least!

The latest BSD internet stack will be heavily reliant on threading, and will be designed to work on multi-core machines (e.g. using lock-free data structures). It would be madness to try and rewrite it for RISC OS’s execution model, so I’d say that the main prerequisite of updating the stack would be a reasonable threading API within RISC OS, and a wrapper layer to provide compatibility with BSD kernel threads + synchronisation primitives.

The latest USB stack is also heavily reliant on threading.

I think there should be a bounty to get WiFi working on the model 3 Pi. Linux seems to have cracked this so it should be a simple matter to do it for RISC OS as well.

Was a bounty established? Given the work that Raik is demonstrating with his Pi-TAB, I think this could become increasingly useful. Maybe as a “chargeable” add-on, too?

Can we use a bounty to develop a paid-for add-on? ROOL were reluctant to have a bounty to update RC14 for the Pi.

Can we use a bounty to develop a paid-for add-on? ROOL were reluctant to have a bounty to update RC14 for the Pi.

Maybe the softloadable WIFI module could be the bounty, and manageable from the CLI, but the user front-end could be chargeable? I can see it would be a HUGE seller in terms of the size of the RISC OS market, and this might add an incentive for a programmer or ROOL. We sorely need WIFI to make RISC OS “portable” so anything that makes it happen should be considered, IMHO.

Was a bounty established? Given the work that Raik is demonstrating with his Pi-TAB, I think this could become increasingly useful. Maybe as a “chargeable” add-on, too?

IMO I think charging for such a key feature, one that is expected in a modern OS, is a bad idea and bordering on something akin to a freemimum-like piece of software.

Folks, I think you’re talking about the design on the roof tiles of a roof that isn’t built on a house that isn’t built.

As Jeffrey pointed out earlier:

The latest BSD internet stack will be heavily reliant on threading, and will be designed to work on multi-core machines (e.g. using lock-free data structures). It would be madness to try and rewrite it for RISC OS’s execution model, so I’d say that the main prerequisite of updating the stack would be a reasonable threading API within RISC OS, and a wrapper layer to provide compatibility with BSD kernel threads + synchronisation primitives.

So,
foundations —> threading API
house walls —> wrapper layer
roof —> port of BSD stack
tiles —> wireless with security

Somewhat more complicated than that, but you probably get the drift. Start with the foundations.

While I am aware of what Steve has posted, I would like to add my voice to the “not a chargeable upgrade” issue. Not because I’m a freetard, I have no problem with it being a bounty, but it does not reflect well on our platform that standard devices that people would expect to work become “value added extras”.

While I am aware of what Steve has posted, I would like to add my voice to the “not a chargeable upgrade” issue.

I totally agree. The reason I didn’t mention it is that it seemed like a secondary issue to the base problem that the network stack needs a bottom up revision.
There is little point in discussing the top when you don’t have the bottom sorted. Castles in the air and all that.

How much of the upper level falls into place easily when the lower levels are done properly?

I completely agree.

RISC OS is stuck in an awkward place. It cannot grow because it can’t reuse pre-existing code. To achieve anything all code has to be hand-crafted, there is no industrialisation (ie making use of components designed by someone else). Even ignoring the lack of developers, this approach simply doesn’t scale.

It can’t re-use pre-existing code because it doesn’t have suitable foundations for it (namely an appropriate scheduling model) which means having to twist the code to fitting the RISC OS interrupt-driven model. That’s a huge amount of work for little forward progress. Massive amounts of work heaped upon few developers means it just doesn’t happen.

Not only the issue of kernel threading, but also at the application level – everything expects preemption these days. We get by with TaskWindow for some things and the pthreads hack for others, but it limits what can be reused. As we saw in the SecureSockets thread, it should be straightforward to pull in a pre-existing userland library from another OS – but, due to various past choices, it isn’t.

Do we have the ability to do it? That I don’t know.

Do we have the ability to do it? That I don’t know.

I’ve learnt enough over the past few years to feel confident enough to add some kind of ‘proper’ threading support to RISC OS (this is after saying early last year that I was hesitant). It’s just a question of being able to find the time to do it – there are still lots of other things I want to do to the OS.

If we can get shareable memory working (that’s my current task), and if we can fix the OS so that it doesn’t flush the cache all the time (although that might be irrelevant?), then we should be able to start playing around with multicore code on the Pi 2/3 (or any other multicore device, if we spend some time getting some sample code for how to start the other cores), using a simple slave kernel. We can use the multicore as a playground for developing a thread scheduler, synchronisation primitives, etc., and then use what we’ve learned there to add threading support to the main core/OS.

If we can get shareable memory working (that’s my current task), and if … … and then use what we’ve learned there to add threading support to the main core/OS.

Would a bounty help make this (wifi support for RISC OS) happen?

That’s the six million dollar question :-)

Since doing wifi “properly” has many prerequisites it would probably make sense to break it down into a series of bounties, similar to the filesystem update one. E.g. step 1: threading, step 2: update core networking stack, step 3: port wifi stack.

But whether bounties actually help or not? No idea. The bounty system has been open for several years now and only a couple of programming-related bounties have been completed. There either aren’t enough people with the right skills/motivation (adding more complicated bounties won’t solve that), or there isn’t enough money going into the system to entice people to do it for the money (more bounties will just dilute the pot further).

I think Theo is completely correct on this issue. All kinds of niche operating systems provide POSIX layers to take advantage of the existing software and expertise around Linux/Unix. Really, I think a compatibility layer that can run on a commodity OS would be the way to go, unless hacking on the OS is the motivation to keep RISC OS going.

Just my opinion. Normal service will now resume. ;-)

Really, I think a compatibility layer that can run on a commodity OS would be the way to go,

That falls foul of the purity laws :)

unless hacking on the OS is the motivation to keep RISC OS going.

Yep, I think that sums things up.

Just my opinion. Normal service will now resume. ;-)

Yep. Thanks for visiting.

… a compatibility layer that can run on a commodity OS would be the way to go

Even if that did conform to the ‘purity laws’, wouldn’t it involve a significant performance penalty? IME RPCEmu performs at about 1/5 the speed of the base system (i.e. WinPC at 3.5GHz = RPCEmu/RISC OS at c.700MHz equivalent).

… a compatibility layer that can run on a commodity OS would be the way to go

Even if that did conform to the ‘purity laws’, wouldn’t it involve a significant performance penalty? IME RPCEmu performs at about 1/5 the speed of the base system (i.e. WinPC at 3.5GHz = RPCEmu/RISC OS at c.700MHz equivalent).

That’s because RPCEmu is a full system emulator. Virtualisation (which I believe is the kind of thing that David is suggesting) will result in near-native performance – generally you’ll get full CPU and memory performance, while I/O will take a hit.

Virtualisation (which I believe is the kind of thing that David is suggesting)

Does that mean – to take a topical example – that single-threaded (i.e. current) RISC OS could get the performance benefit of multi-threading if running virtually on top of a multi-threaded OS?

If you have a single-core version of RISC OS then it would still be limited to running on one core.

But if you’re feeling masochistic there’s nothing stopping you from running multiple copies of RISC OS and getting your multi-threading that way ;-) The hypervisor running on the host (if it’s any good) should make sure that the different instances get spread evenly across the different cores.

Seems to me then that if one is going to spend time and effort, there’s no point in working on virtualisation without first attending to the shortcomings of the OS, which is a roundabout way of saying it’s better to be devoting effort to improving RISC OS as a native OS, which is what you’re doing! Just my ha’porth.

Well, you could argue that the “best” parts of the operating system are the user-facing parts, or in fact the applications. The selling points of the user interface were always things like font rendering, drag and drop, self-contained applications, and so on, but a virtualised solution would use the host system’s support for those things. The nicer parts of the underlying OS are things like image file systems which are present on other operating systems in some form or other, so there’s no need to run the original code for those.

Basically, all you really want is something that emulates execution of application code, maybe with some form of “acceleration”, or runs it natively on another ARM platform with hooks to intercept SWI calls. You would be handling those calls in a way that would be faithful to the way RISC OS handles them, and some of them would be passed through to code on the host that renders graphics, accesses files, reads input devices and so on. Some handling would be purely within the compatibility layer – maybe things like presenting memory to the application in the same way that RISC OS would do so, or maintaining the illusion of cooperative multitasking.

But, effectively, I’d imagine that you’d run each application in a separate sandbox and use the host operating system’s facilities to do things like drag and drop, copy and paste, and message passing.

I think this is what Riscose was going to do. It’s a lot of work which could be made easier by initially relying on the existing RISC OS code for parts of the compatibility layer where it would just be tedious to implement something that behaves like the system you’re trying to replace, especially if that system is going to be redundant eventually.