Jump to content




[Kernel] kKernel - A complete base for OSes v0.2

api

29 replies to this topic

#1 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 20 December 2014 - 06:58 AM

kKernel (KiloKernel)

version 0.2


After being inspired by numerous projects such as ccLinux and Leadlined-Kernel, I decided to have a crack at it myself and implement my own version of a kernel.

Screenshots



Active Developers:
  • Mr. Bateman
  • awsumben13
Some notable main features so far are:
  • Adds a "compatibility layer", which does all sorts of amazing things, like allowing non-colour computers/monitors to run colour programs, and workarounds to the infamous LuaJ byte-parsing bug.
  • Modular-based system allows you to add your own custom modules, and you can even load modules while the system is operating.
  • Peripheral Module allows you to use "drivers", which can run snippets of code when a peripheral is interacted with, such as when it is attached and detached, and even allows you to change how peripheral.wrap works! It gets even better, as it allows you to create virtual peripherals, and even spoof physical peripherals, allowing things such as virtual printers!
  • Filesystem Module adds a metadata system, where it saves the last accessed, modified and created time in the '.$MFT' file. Permissions are coming soon.
  • ELF and compiled Lua compiler and executor, with a variety of formats and types. Documentation: Soon™
This should be 100% compatible with any code you throw at it that can run in CraftOS (Even OSes), but please inform me of any that don't.

If you want to have a look at more features, documentation and the FAQ, it's all over at the Github Wiki.

You can have a look at the code in it's current state on it's Github Page.

I plan to make an automated installer once I feel okay with the amount of content in it, but right now it's stable enough for releasing here.

Please, post any criticism, comments or suggestions! Bug reports are fine too!

Edited by Mr. Bateman, 24 February 2015 - 12:44 PM.


#2 ByteMe

  • Members
  • 124 posts
  • LocationAdelaide, Australia

Posted 20 December 2014 - 10:45 AM

hate to be the one to say it but "no pics, no clicks". I did however have a look and I couldn't find anything bad.

Edited by ByteMe, 20 December 2014 - 10:46 AM.


#3 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 20 December 2014 - 10:57 AM

This looks really nice. One thing though, for metadata, it would be nicer if you could implement Lyqyd's metadata 'standard'. This would mean you have compatibility with other Operating systems/programs. Other than that, I really like this idea.

#4 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 20 December 2014 - 11:53 AM

View PostByteMe, on 20 December 2014 - 10:45 AM, said:

hate to be the one to say it but "no pics, no clicks". I did however have a look and I couldn't find anything bad.
I'll put some pictures of the boot sequence up soon.

View PostSquidDev, on 20 December 2014 - 10:57 AM, said:

This looks really nice. One thing though, for metadata, it would be nicer if you could implement Lyqyd's metadata 'standard'. This would mean you have compatibility with other Operating systems/programs. Other than that, I really like this idea.
I had a look at that, and while I agree with how extensions and filetypes are handled, I don't like the idea of separate files for each metadata entry. It fragments the data itself beyond belief, and makes it harder to manage the individual files. It's also not good for programs themselves to have (direct) access to modifying the metadata.
I'll take what I can, but it's a pretty good suggestion nonetheless.

#5 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,464 posts

Posted 21 December 2014 - 09:00 PM

It doesn't really fragment the data--there's no real advantage to putting all of the metadata in one monolithic file. As well, the metadata for mounted drives has to be stored on those drives, so there will already be some level of "fragmentation". The file-per-file structure makes it easier to access exactly what's relevant at the moment. Of course it is a good idea to give direct access to the metadata, any API one designs wouldn't be able to account for any and all new functionality others may want to implement using the data. A sufficiently powerful API would amount to direct access anyway. In any case, it comes down to a matter of philosophy. I'm more along the lines of an open, allow-the-user-to-break-things-if-desired philosophy.

#6 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 22 December 2014 - 02:46 AM

Well, if you put it that way, then all my concerns are addressed. I'll be sure to add this to the next version.

#7 tenshae

  • Members
  • 66 posts

Posted 23 December 2014 - 12:38 AM

This is a surprisingly good kernel. You could totally make an OS off of this, as it stands.
INB4 "kernels" become the new NDFJay Tutorials, and hundreds of noobs make OSes from this and an hour with Bedrock.

Edited by ashnwill, 23 December 2014 - 01:10 AM.


#8 jaredallard

  • Members
  • 124 posts
  • LocationSeattle, WA

Posted 23 December 2014 - 05:29 PM

First of all, I love you for saying you were inspired off of ccLinux, getting quite hard to develop that as of recently :/

Second of all, this is some solid code. Great job! If you plan on implementing any sort of standards that are unusual, *please* let me know because I'd love to support compatibility with this in cclinux.

View PostLyqyd, on 21 December 2014 - 09:00 PM, said:

It doesn't really fragment the data--there's no real advantage to putting all of the metadata in one monolithic file. As well, the metadata for mounted drives has to be stored on those drives, so there will already be some level of "fragmentation". The file-per-file structure makes it easier to access exactly what's relevant at the moment. Of course it is a good idea to give direct access to the metadata, any API one designs wouldn't be able to account for any and all new functionality others may want to implement using the data. A sufficiently powerful API would amount to direct access anyway. In any case, it comes down to a matter of philosophy. I'm more along the lines of an open, allow-the-user-to-break-things-if-desired philosophy.

Not true, storing vast amounts of data in one file as apposed to multiple is faster. The less FS calls you can make; the better.

#9 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,464 posts

Posted 23 December 2014 - 10:47 PM

You can't store it all in one file anyway, and moving/copying/deleting/adding metadata only involves 0 (or 1, for adding) file opening calls in a file-per-file setup. The fs calls for copying/deleting/moving themselves are fairly fast. As I have mentioned elsewhere, LyqydOS implements the metadata system and there is no noticeable difference in speed between having and not having the system in place.

#10 tenshae

  • Members
  • 66 posts

Posted 23 December 2014 - 11:26 PM

View PostLyqyd, on 23 December 2014 - 10:47 PM, said:

You can't store it all in one file anyway, and moving/copying/deleting/adding metadata only involves 0 (or 1, for adding) file opening calls in a file-per-file setup. The fs calls for copying/deleting/moving themselves are fairly fast. As I have mentioned elsewhere, LyqydOS implements the metadata system and there is no noticeable difference in speed between having and not having the system in place.

This is starting to look like a microkernel vs. monolithic kernel debate...

Edited by ashnwill, 23 December 2014 - 11:26 PM.


#11 jaredallard

  • Members
  • 124 posts
  • LocationSeattle, WA

Posted 24 December 2014 - 01:34 AM

View PostLyqyd, on 23 December 2014 - 10:47 PM, said:

You can't store it all in one file anyway, and moving/copying/deleting/adding metadata only involves 0 (or 1, for adding) file opening calls in a file-per-file setup. The fs calls for copying/deleting/moving themselves are fairly fast. As I have mentioned elsewhere, LyqydOS implements the metadata system and there is no noticeable difference in speed between having and not having the system in place.

Now think about doing that over a vast sum of files, i.e over 1M or etc. It still adds up. In general, using more FS calls is bad and should be avoided whenever possible.

#12 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,464 posts

Posted 24 December 2014 - 02:04 AM

One million files wouldn't fit in a default-configured computer's storage space, depending on how file size is calculated. If it goes by the space files actually take up on disk, not even three hundred empty files would fit on most systems (assuming 4kB block sizes). Either way, it essentially comes down to a matter of opinion. Both ways have their advantages, I just happen to think that file-per-file offers more/better advantages than file-per-drive.

#13 jaredallard

  • Members
  • 124 posts
  • LocationSeattle, WA

Posted 24 December 2014 - 06:40 AM

View PostLyqyd, on 24 December 2014 - 02:04 AM, said:

One million files wouldn't fit in a default-configured computer's storage space, depending on how file size is calculated. If it goes by the space files actually take up on disk, not even three hundred empty files would fit on most systems (assuming 4kB block sizes). Either way, it essentially comes down to a matter of opinion. Both ways have their advantages, I just happen to think that file-per-file offers more/better advantages than file-per-drive.

It's a matter of opinion until proof of concept tests show otherwise.

#14 KillaVanilla

  • Members
  • 303 posts

Posted 24 December 2014 - 09:25 AM

This looks like an interesting project. I look forward to seeing what comes of it.

#15 tenshae

  • Members
  • 66 posts

Posted 25 December 2014 - 06:19 AM

Yeah, I'll definitely be experimenting with this.

#16 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 24 February 2015 - 12:47 PM

v0.2, a much needed patch.
Changelog:
+ Added performance tweaks such as top level coroutine override (--tlco) and (partially working) window API override (--noWindow), thanks to research and code by oeed, Bomb Bloke and Geforce Fan
+ Argument passing and handling should be fully working now
+ A complete and functional ELF implementation
- Filesystem module (and by extension $MFT and file information) is now disabled by default due to performance issues, use --full to enable it again

I plan on adding certificate signing to kernel files to make sure they aren't being tampered with, but I might end up not doing it thanks to floppy drive overrides. RSA implementation is also going to be a pain.

#17 tenshae

  • Members
  • 66 posts

Posted 24 February 2015 - 10:05 PM

View PostMr. Bateman, on 24 February 2015 - 12:47 PM, said:

--snip--

Wow. This is amazing!

#18 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 25 February 2015 - 09:52 PM

Here's a tip: This default function overwrites the term API:
term.redirect(redirectTarget)
The term API is actually just the functions your buffer contains, with the exceptions of things like term.redirect. If you've successfully replaced everything it calls, you'll be able to redirect to that table just fine.
---
I cannot get this kernal to execute my code. I'm doing
shell.run"kernel.sys/boot /main"
and it tells me it reached the end of execution.
--
For cleanliness purposes, when redirecting to the native shell, I would do this
window = nil
multishell = nil
although, this will cause multishell to break when returning to it. Simply running the shell fixes this.
People shouldn't not check for these to not exist; basic computers & pre-1.6 computers don't have these.
---
While hanging, you should be doing this:
while true do
coroutine.yield()
end
Currently, after 9,999 seconds this will stop and someone has access to your computer. Or, if you prefer, ~2 3/4ths hours.

Edited by Geforce Fan, 25 February 2015 - 10:05 PM.


#19 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 26 February 2015 - 06:24 AM

View PostGeforce Fan, on 25 February 2015 - 09:52 PM, said:

I cannot get this kernal to execute my code. I'm doing
shell.run"kernel.sys/boot /main"
and it tells me it reached the end of execution.
I've forgotten to change the entry in the wiki. You should be using:
shell.run("/kernel.sys/boot", "--boot [your program here]")
Thanks for the other tips though, I'll be sure to implement them.

#20 ElvishJerricco

  • Members
  • 803 posts

Posted 26 February 2015 - 05:34 PM

Your elf format is... Bleh. Its only real feature over just using a plaintext lua file is the arguments thing, and I'm struggling to understand the point of that. I'd be super interested in an actual elf format, where it dynamically adds functions to the bytecode with a dynamic linker, so that external libraries can be used as though they were local. It could replace all these instructions
getglobal "functionNameFoundInDynamicallyLinkedLibrary"
with these instructions
"closure #indexOfDynamicallyLinkedFunction"

But this would require a special compiler for the libraries... This is an interesting idea.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users