Developer meeting / doing kernel in C

Hi everyone!

EDIT crap misspelling in topic!!

I think that it is a good time to try to consolidate what people are doing with RISC OS now and what they plan for the future.

I think that moving to C seems like the next logical step, preparing for ISA shift that will need to happen sooner or later. This can ofcourse be discussed, I am not forcing anything.

I propose that we put together a little virtual developer conference (with zoom or big blue button (like zoom but opensource)).

A channel of communcation (apart from forum) that developers actually use for realtime communication would be good. Can be ChatCube or IRC.

SOmeone please change top line !

SOmeone please change top line !

Probably not even possible on the Beast. Never mind, you noticed it was wrong, unlike some frequent contributors to this forum who are genuinely word-blind. But what have Individual Savings Accounts got to do with RISC OS?

Sorry for not being clear: ISA Instruction Set Architecture
About the topic line , English is not my native languge.

If a admin would do the favour .. copy contents delete the post make a new one and paste in content.

Sounds like a great idea Michael :)

If it’s on a Saturday or Sunday I am in. Thanks!

unlike some frequent contributors to this forum who are genuinely word-blind

Humm I feel like the word-blind one… if so, sorry Gavin!

If it’s on a Saturday or Sunday I am in. Thanks!

That will ofc be on a weekend.

SOmeone please change top line !

Thanks , Thumbs up!

Humm I feel like the word-blind one… if so, sorry Gavin!

You are absolutely not the one, I assure you. I am the one who should apologize, for having even mentioned such a word.;)

@Michael. By moving to C did you mean from ARM assembler ? In which case I certainly agree. But at the moment the shared C library cannot use VFP or Neon, which prolongs in a rather brutal way the historic unsuitability of RISC OS for any applications needing floats, unless GCC is used. We are rather short on tools to produce executable code. In the past I preferred Norcroft over GNU because it was more compact. But now it has to be GNU, and it worries me that we do not have other options.

PS. Glad to see that the Beast can be tamed.

By moving to C did you mean from ARM assembler ? In which case I certainly agree. But at the moment the shared C library cannot use VFP or Neon,

I am aware, the qestion is how much of clib do we need?
There is a very small stub in HAL, which I have used . I think it might be worth investigating using Norcroft to start with.

When I say kernel , I mean Kernel, not the complete ROM.

There are things , MMU activation is a good example that needs to be assembler.

I’d be interested in attending such a call. I get extremely little time to work on RISC OS these days (family etc) but I did make a start on reworking the window manager in to C some years back and would be happy to share my experiences of that.

but I did make a start on reworking the window manager in to C some years back and would be happy to share my experiences of that.

Thanks, that would be great!

There is a IRC channel on freeenode , for kernel talk.. ##riscos_kernel . Please join if you are interested in talking kernel directions/plans.

Update.. new irc channel

Update.. new irc channel##riscos_kernel

Update.. new irc channel##riscos_kernelI registered it.

Alright!

I suggest a meeting first weekend of february.
Saturday 6/2. We need someone who can host it.

What kind of meeting?

While I understand you David I think that it makes a hugh difference whether to have an online (Video & Audio) or a chat meeting. Unfortunately there is no online meeting option on RISC OS that’s true. Still I think that for an effective meeting it would be the better option. And a youtube video may be published afterwards – which can be watched on RISC OS. But I agree that it would be good to also have a protocoll of the meeting.

I suggest a meeting first weekend of february.
Saturday 6/2. We need someone who can host it.

https://meet.jit.si/ works in most modern browsers, though probably not in any Risc OS. Might be an alternative though.

About meeting:
I think a video enabled meeting is to be prefered.
It is very hard to keep track on who is saying something in pure chat meeeting.

Kernel:

I can see three scenarios:
1, Start with Kernel, modularise it and start adding C code.
2, Start with a minimal HAL (Top and Debug) and work the way from there. Doing new code instead of Kernel, but following what Kernel do.
3, Use microkernel , in my case Genode/base-hw. Skip all lowlevel stuff like mmu and implement Kernel as a server. ARM32 emulation can be added.

I lean towards a combo of 2 and 3.

What do you think?

Can you give us a quick tour of what genode is, and how a kernel would sit on top of it?

For option 3, is it possible to do it in such a way that the same kernel code base could work with both genode and any existing HAL + mmu and other stuff left over?

For option 3, is it possible to do it in such a way that the same kernel code base could work with both genode and any existing HAL + mmu and other stuff left over?

My understanding of the online documentation for Genode is that it runs quite happily on ARM or x86 etc so Genode is effectively the HAL and presents the pseudo base environment as a ‘bare’ server with an emulated 32 bit or whatever environment as desired.

The beauty of it is that genode adds the security we keep talking about, it emulates a basic ‘hardware’ environment and can pass through the various hardware devices from the real hardware. Various micro kernel variants (Michael has used base-hw)

Documentation available here
and the main documentation is here (online) or a PDF

For option 3, is it possible to do it in such a way that the same kernel code base could work with both genode and any existing HAL + mmu and other stuff left over?

Not sure , I think a "Next generation " RISC OS will be a fork. It will be hard to maintain it as a patchset.

that said…

I think that current RISC OS could benefit from a total make over. Bits and pieces can be backported.

The first option , modularise Kernel is probably good both for current RISC OS and for a remaked one.

A important note is: I like RISC OS as it is , and do not want to change the way it works. I just want to change what happens in the background. This is very complicated if we want to keep compatibility. SWI is a good example of a problem. In theory it can be solved with a shared library system , but that still means that apps needs to be rwritten. This is why some way of emulator is needed, and make that somehow bridged.

A lot of things to think of.

ROUGOL currently has a paid Zoom account which could be used to host a developer meeting (same for WROCC and MUG I expect).

https://meet.jit.si/ works in most modern browsers

We considered this for ROUGOL meetings (because it’s free!) but found it kept breaking on different browser/OS combinations, changing from one week to the next :-( Maybe it has stabilised by now.

Hi and there it pops up again :
“I think that current RISC OS could benefit from a total make over. Bits and pieces can be backported.”
If you want to talk about that I think a better way is the Linux Port. A total makeover is really a lot of work a splinters scarce time and resources

I think that by a linux port RISC OS would stop being unique and definetly incompatibile with RO software.

think that by a linux port RISC OS would stop … definetly incompatibile with RO software.

That is demonstrably false.