Using HIDs

The GPL licence struggles with this concept.

The GPL struggles with a number of things, the so-called freedoms it and FSF speak so highly of being one of them.

Unfortunately the GPL does not make provision for relicensing, once under the GPL always under GPL.

Not so. The copyright holder has the right to release code under multiple licences. Removing the offending code mean’t Castle no longer had to release code under GPL. The GPL’d version of HAL was supplied complete with code which is all that was required. What the GPL licenced HAL does mean is that anyone aquiring that version of may only use it with a GPL licence

Removing the offending code mean’t Castle no longer had to release code under GPL. The GPL’d version of HAL was supplied complete with code which is all that was required.

If David checked Gerph’s ramblings he would also find that both Justin (who discovered the GPL code) and people from FSF had acknowledged that Castle had:
1. Released the source of that version of the HAL as required.
2. Rewritten the HAL without the GPL code as required for its release without inclusion of the source.

The mis-understanding people seem to have is thinking that putting a small amount of GPL code into something makes the whole item GPL forever. The GPL itself acknowledges the existence and allows for the use of proprietary code in an otherwise GPL scope. The GPL also acknowledges that the proprietary code remains the property of the author.

The GPL speaks about what the receiver of the code can do, i.e. what you (as a RiscOS user) is allowed to do with the code. You are not allowed to change the licensing of the code. The author of the code (the copyright holder), however, do whatever s/he wants, including changing the license or using different licenses on different occasions.

As to the limit of calling SWIs, there is nothing saying that a module can not implement a dirrectly callable interface, so long as it is well defined and implemented in a consistant manerAs to the limit of calling SWIs, there is nothing saying that a module can not implement a dirrectly callable interface, so long as it is well defined and implemented in a consistant maner.

Which would be this “collusion” you speak of, surely?

Indeed, given what the hardware interfacing code does, I am inclined to think that it should be kept out of a module and be available at a lower level.

Certainly, the distinction between your hardware module and a HAL is a trivial one. I presume the module will set itself up and provide a call to initialise the linkage mechanism, yes? Well, a HAL is basically the same thing only the linkages are sorted out at compile time.

Remember – the ARM SoCs cannot be autoprobed like PC hardware (go ask the stressy Finn!), so each SoC will need a custom build. Therefore a custom build with a custom HAL for each platform is not so onerous.

The kernel should provide very basic support for:
* Memory management.
* IRQ assignment.
* Page Mapping.
* Initialization of modules.

It should provide mid-level/high-level memory mapping (managing memory and pages ought to be the same thing). It should also provide higher-level interrupt handling.
The HAL (or whatever) should take these abstract concepts and apply them to the hardware. The kernel should not be talking to the MMU. It should not be overly concerned with the specifics of how memory is arranged. And absolutely it should not be hanging on to any preconceptions of interrupt mapping. IRQ#7 might be USB on one device, GPU on another device, and sATA on a third device. The kernel should know “USB wants attention” and “sATA wants attention”.

The ultimate goal is to have a generic kernel hooked to a chip-specific HAL. The HAL will change, depending on the target platform. The kernel will not.

There is, however, another fly in the ointment. Hardware code in a module will be horribly incomplete. If you look at the bringup code, you will see there is quite a lot of system-specific stuff required before the modules are even looked at. This means your choices are:

1. Have system specific code in a sort of mini-HAL and the rest, or duplicates, in a hardware-driver module.
2. Some God-awful mess where code that is nominally part of a module is called directly prior to the module table even being scanned.
3. Just write a chunk of code with a defined API, call it the HAL, stop getting hung up on semantics.

Even CLIV should be in its own module.

Didn’t ROLtd do stuff like this?

I know that there are those that would dissagree, though think about it for a while.

I don’t disagree. Certainly it might be good to split the kernel up a bit so it isn’t carrying around the baggage of OS_Byte.
One might say that a lot of the SWIs don’t belong in the kernel – Args/BGet/BPut/File/GBPB/etc could be a FileSupport module. The Heap/HeapSort/CRC/ReadUnsigned/ConvertXXX/ReadArgs/etc could be a Toolbox module. There should be a generic VDUdriver module for WriteX/Remove|RestoreCursors/SpriteOp/ReadVDUVariables/CheckModeValid/ScreenMode/etc.

I would imagine the ROOL developers would agree that rationalising the kernel would be a good move, however there are many more important things to do than take the kernel apart. Think about it, would we like to have RISC OS enhanced feature-wise (re. Jeffrey’s work on GraphicsV) or would we be happy with lots of work to make a RISC OS that looks and feels exactly the same as it did beforehand?

It would also help break things up, as the hal is a monolithic beast.

Kernel != HAL

Also does not the current implementation have some number of modules that can not be unpluged, and can not be killed?

I thought only UtilityModule enforced the cannot be killed part? I haven’t tried.
Of course, if a person wants to *Unplug BCMVideo and the USB stack, they shouldn’t come crying here when their Pi appears to have died…

How is this different than providing modules that can not be unplugged or killed for HW support, and making sure that they are in the first N modules of the ROM.

…because as I have said just above, there is an amount of hardware support necessary before we even get as far as “modules”.

Also it would make the developing new HW support so much easier.

Why is looking in “/Sources/HAL/<platform>/…” difficult? Okay, granted, video drivers (BCMVideo, OMAPVideo, USB drivers, etc are separate modules; however the HAL is primarily involved with the hardware that the core of RISC OS requires. Hardware interactions for kernel services, if you will; so it could be argued that non-kernel system drivers might be better off in their own module (possibly using the HAL as “glue”?).

This is the Elephant in the room that every one refuses to talk about.

Oh, I’ll talk about the cancer that is GPL if you like. You might have guessed from my reply that I have very specific thoughts about GPL. Actually, I do not disagree with their mission and what they have succeeded in achieving. What I strongly disagree with is all the self-righteous spouting of the desire for “freedom” coupled to a licence that, in many cases, requires associated code to become GPL itself (this being the “cancer” aspect of it). We’re on GPL v3 after many years of GPL and there is still no clear answer with regards to GPL libraries being linked to non-GPL software. FSF is in favour of infection, to help spread the good word of GPL; though the exact and actual terms of said infection are unclear (and the wording of GPLv2 and GPLv3 differ on this point).
Yes, I am using the word infection. I, as a matter of course, will not touch GPL code if there is any alternative. I have been known to rewrite entire chunks of code just to avoid using anything tainted by the GPL.

There are numerous OSI approved “open” licences, the GPL co-exists with exactly none of them. So much for freedom.
I also disagree with the religious fervour attributed to proponents of the GPL to a state only otherwise seen in the proximity of Apple shops; leading people to believe rubbish such as this:

Unfortunately the GPL does not make provision for relicensing, once under the GPL always under GPL.

That is, unfortunately, a half truth.

I can release a program, let’s call it !Xyzzy version 1.00 under the GPL. You get the sources, you get the GPL. You can fork it, hack it, whatever you want within the constraints of the GPL. Forevermore, for derivations from that code. I cannot rescind your rights under the GPL.
Tomorrow, I can change the version to 1.01 and release the exact same source under the EUPL. You can play with the source, hack it, etc within the provisions of the EUPL (which includes relicencing to a different compatible licence model, as the EUPL understands what freedom really is, unlike Mr. Stallman et al). Forevermore, for derivations of that code. I cannot rescind your rights under the EUPL.
The following day, I can remove all traces of the code from my site and say it is no longer an open source project. I may still be obligated to provide sources to those who ask who are using the open source versions; and there is nothing I can do to stop the open source versions that exist – I could not prevent you from maintaining !Xyzzy on your own, distributing the source code, etc. Those are valid provisions of the licence that came with that version of the program. However, I can pull the distribution and make it commercial proprietary, if I want.

In short, I can licence my software however the hell I like when I like. Because I am the legal legitimate copyright holder.
You… get to obey the licence. With GPL, you are bound by GPL. Because you are not the copyright holder, so you can only relicence if the licence itself permits this.

Do you see the difference? As the creator, I am not bound by a licence the same way that you would be. I have the freedom to choose, and to change my mind.

Now, mind you, if I relicence Xyzzy to EUPL or a restricted licence, this does not alter any GPL versions that might be in the world. They still exist, and will continue to do so. However there is a metaphorical brick wall between the old (GPL) version and the newer version. One cannot depend upon the code of another (licence clash). So if the GPL was abandoned for something else, it would become frozen in time and would need to be updated independently. Essentially Xyzzy-GPL and Xyzzy-SomethingElse would be two entirely different entities.

This should answer the following:

I also point out that in the GPL release castle had explicitly noted these files as being under the GPLv2 in the comments, and the same almost completely unchanged files show castles propritary license, this alone violates the GPL.

As Castle are the creators, they can release all of that code to be GPL to be within the requirements of the GPL.
They then took out all of the (originally) GPL code and relicenced their own code to something else.
This does not violate the GPL – rather the GPL trying to prevent this would violate an author’s basic rights.

Sorry READ THE GPLv2 you can not relicense.

Rubbish!

VLC went from GPL to LGPL (so it can be included in more projects reducing the cancerous side effects).
MySQL is dual-licenced (GPL and commercial, to completely remove the cancerous side effects – the commercial licenced version is not GPL so the GPL does not apply, period.)

What you want to say is:
Sorry READ THE GPLv2 you can not relicense. as in you (yes, you) cannot relicence my code. I, on the other hand, can do whatever I want with it.

GPL is an interesting hack to the international copyright framework to essentially provide a guarantee of freeness. I cannot rescind the permissions I give you in a piece of GPL code. Subsequent code, I could change the terms. But not the stuff you already have.
However – note well – GPL is concerned with redistribution rights. In other words, it tells you what you can do with my code. No more, no less.

Before telling us, in capitals no less, to read the GPL; please brush up on what the GPL actually is and how it fits in with existing copyright; particularly the very important distinction of whether or not one is the copyright holder.

And there is the little detail:
IF it were true that you need all of this extra before dealing with HW then most OSes that run on ARM SoCs either would not or would have to be almost completely rewritten from what they are.

Actaully you forgot a rather large detail – the other OS offerings on ARM run dog slow because they are generalised. Whereas sizeable portions of RO are custom built for ARM. The HAL is a means of peeling out the previous dependence on specific hardware chips that the new machines don’t have.
I suspect the person who could argue the case for the HAL to the utmost is Jeffrey, but I believe his time is better spent doing what he clearly likes doing – writing code for the new architecture.

Do note that the teams of people re-writing Linux or whatever for ARM are rather bigger than the RO team yet the Linux people seem to take as long to produce something for a new device like the Pi as a couple of coders working on a modification of a HAL.

So tell us again why its a bad idea…

At the prompting of some of the people I have read most of Fustin Fletcher’s Rambles, and note that RISC OS Ltd, had aparently made significant progress toward doing exactly what I am suggesting, before they began to focus on the Emulation only market (So I guess that I am not the only one that thinks it is a good idea). And Having an old copy of RISC OS Select 6, I do not see it being any slower than RISC OS 5.20 on a RiscPC (some things are notably faster), I can not speek of how portable it is as we do not have the sources.

Most of the modularisation was done to split the functionality to speed later development, I think Justin said that in parts of the Rambles, most of the rest was to put in features that specific interest groups wanted at the expense of not carrying out 26/32 bit neutral work until after the fork development of RO5 appeared with the Iyonix.

I hazard a guess that if the build was easy to port to new architectures ROL would have done it to open up a new hardware market.

Though that does bring up the question; Justin Fletcher sais that he had sold his share in RISC OS Ltd. to Castle, how does that affect our access to to modifications to RISC OS that he had contributed?

Not even remotely affected. Justin was working for ROL, arguments about whether all the source of the developments that finally got labelled RO6 ¹ was passed to Pace and then onto Castle with the Castle acquisition of the IP would fill books enough for a library. What is known is that ROOL do not have those source files.

Or is there some one talking to 3QD about the stuff from RISC OS Ltd?

Aaron (3QD) was a director of ROL and let’s just say I can’t see him playing happy families with Castle or ROOL anytime soon. Hence the bits in the ROOL developments where things are sometimes re-inventing the wheel, there simply is no dialogue.

¹ Named RO6 presumably because 6 is bigger than 5.

Named RO6 presumably because 6 is bigger than 5.

Presumably, but what a PITA for version checking. Something instilled in the Acorn way of doing things is that later versions of modules offer enhanced functionality compared to earlier, but ought to be largely backwardly compatible.
RISC OS 6 breaks this.

With stuff like *RMEnsure, I just pretend RISC OS 6 does not exist. In code, I check the code is running in a 32 bit world and has a HAL. But, again, I more or less ignore version 6. I mean, a few years of development down the line…what, we’ll leapfrog to version 7? I guess somebody at some point thought it would be cute to one-up Castle and call the next version “6”, the difficulties of having then two disparate versions of the OS, but from a development point of view, it is an annoying complication, don’tcha think?

let’s just say I can’t see him playing happy families with Castle or ROOL anytime soon

It’s a shame. I can understand wanting to secure supply of RISC OS once ROLtd faded away, after all his big product depends upon it. However, the flip side is that there are two versions of RISC OS and one is being developed. Ours might be simpler in the UI sense, we don’t have the RISC OS 4 bells and whistles, but we do have work ongoing towards a version of RISC OS that will be more and more capable (such as the GraphicsV enhancements, et al), which means as work here progresses, the version(s) bundled with VirtualAcorn will not progress.
Given that there is an IOMD version of the OS (so it should technically work with the emulator), surely the best approach for everybody is some form of constructive dialogue?

The only defensible reason for moving code out of the kernel and into a module is because you want to be able to remove or replace it.

You cannot remove OS_Byte or OS_CLI.

You can replace both by using vectors.

ROL’s penchant for putting everything in a module achieved nothing but introducing new bugs.