Cosmos
Cosmos copied to clipboard
[feature request] kernel arguments and modules
i think kernel should have access to arguments and modules passed to them. for arguments we need to plug Environment.GetCommandLineArgs()
and for modules we need to implement special class for it. as cosmos cant read iso data at any circumstances, modules are very useful in our case
sorry, i forgot to mention that these features need to be implemented through multiboot2, which cosmos is currently using. it provides kernel arguments and modules
@AsertCreator And how would the user pass those arguments?
using limine's built-in config editor. note that, nowadays, every kernel can support console arguments, like windows nt, xnu, linux, freebsd. so wouldn't we support it?
p.s. it's not primarily for end-users, but for debugging
using limine's built-in config editor.
No I didn't mean like that.. I mean, how are they actually going to pass arguments? Like -resolution 640x480x32
for example. Is it going to be implemented as a csproj setting? If so that'd be incovenient (but I don't really see any other option to be honest)
p.s. it's not primarily for end-users, but for debugging
That would make even less sense in my opinion, because then why would you have them if it's almost never going to be used?
I mean, how are they actually going to pass arguments?
again, limine has a built-in config editor, where you can change kernel arguments and modules. it works like a text editor. you can change them right before booting
why would you have them if it's almost never going to be used
arguments can be useful to enable or disable some features, as it's impossible to store settings as cd file, because cosmos can't even read cd. some features can lockup system, so developer needs an easy way to disable them without recompiling, because il2cpu in pair with yasm are slow
again, limine has a built-in config editor, where you can change kernel arguments and modules. it works like a text editor. you can change them right before booting
That would be a bad and convoluted way in my opinion.
arguments can be useful to enable or disable some features, as it's impossible to store settings as cd file, because cosmos can't even read cd.
That's only temporary, in that it's not broken forever.
some features can lockup system, so developer needs an easy way to disable them without recompiling, because il2cpu in pair with yasm are slow
Again, one could use the file system.
how would you modify cosmos file system? "mounting, modifying, then demounting" sounds like a slow process. developers cant add files to iso, becuase cosmos cant read either ide cdrom or sata cdrom, also they may modify vmdk, but it takes way too long. modules are also good idea, despite fact that limine can load only one module. using modules we can split oses, maybe putting some user programs onto it, or kernel settings. im talking about present, not future
whats about real hardware? you need to recompile os to change parameters, then flash it into usb stick, then boot target pc from that stick, only to see that something is not working and then doing this whole process again. same with vms, but its apparently faster, but not significantly. network boot is not faster in any way, plus its pretty difficult to create a pxe server
if we use kernel arguments to enable/disable/modify os features/behaviour it would be much faster and simpler. just resetting vm and changing arguments. again, it is not for users, but for os developers. user doesn't need to modify kernel arguments, but for debugging it is very useful
also, why wouldn't cosmos support kernel arguments, if literally every popular os/kernel supports it. like in winnt, linux, xnu, even osdev hobby kernels. cosmos exists for more than 15 years now and it needed to support it from very beginning. this feature isn't any hard, multiboot2 specification supports them both as simple tags
please be realistic it is faster than "recompiling entire os using il2cpu which takes around a minute, then yasm to compile it for half-minute then waiting for vm to startup". dont you want for os debugging to be faster and easier?
for kernel arguments if we do ti we should just copy how linux does it
for kernel arguments if we do ti we should just copy how linux does it
exactly