Hi
On Sat, Mar 15, 2008 at 1:21 AM, grover <[EMAIL PROTECTED]> wrote: > Hi, > > I just stumbled upon SharpOS about two days ago and have been reading things > on the website, wiki and browsed through the source code. The website really needs more documentation and the documentation that we have is mostly unfinished. I blame everybody working on the engine instead of documentation, which is understandable at this stage.. But hopefully the documentation will be improved upon in the future. > 1. Are there any plans to support real plug&play (as far as it is possible)? Yes, eventually we should support plug & play. > 2. Do you have any plans to support reflection in the kernel level? Yes, Internally in the kernel after all the required subsystems to make it work have been initialized. As for being able to use reflection on the kernel from the outside... only if it doesn't hurt security > 3. Is the kernel (and its drivers) going to be reentrant and thread safe? Yes. > 4. Are you going to support checked channels (similarly to Singularity) to > enforce proper usage of interfaces? We haven't gotten to that point yet, but currently the most popular idea is to use the JIT compiler (it's not implemented yet) to dynamically glue interfaces between processes together.. Since from both sides of the communcation channel you'd be using regular safe C#, the channel will be safe as well. > 5. What kind of security model do you want to support (ACL or *nix-style?) ACL. > 6. You are developing a new IL based shell for SharpOS, but why are you > reimplementing bash (Nash) and the unix toolset? ... I suppose you're reffering to SharpOS.Unix? that's not an 'official' part of SharpOS. As for the current console; it's only there for testing, i'm sure it'll change dramatically over time. (and we're always open for suggestions) > 7. On the wiki you are specifying that you do not want to provide a > *nix-like /dev filesystem? Why is that? ... It's because the only reason to expose devices trough the filesystem like that is that you can write to/read from them as if they're files. Problem is, filesystem data is not structured, so you could send whatever binary data that you want to the device, which is a security risk imho. It's better to expose these devices trough another way which is structured and safe. (the debate is still ongoing about this by the way) > 8. The filesystem again: I think we should expand this a lot more. Adding to > what I said in the previous point I'd love for applications to be accessible > from the filesystem, think of accessibility, automation and scripting. Other > operating systems require apps to register themselves or class factories to > enable other apps to access them, we could automate a lot of this and enable > a lot more > interaction between apps. Right now the idea is that we'll have an application directory, and applications 'register' themselves simply by having their own directory there. That way you wouldn't need to register anything.. the OS would 'discover' the application by looking what directories are in the application directory. We haven't thought about automation and discovery between applications, it's a good point to bring up.. > 9. Has a driver model been decided upon? I would like to help there first as > I believe this needs a lot of care. I would like to propose a > self-descriptive driver design, where drivers describe themselves (e.g. > PnP-Ids supported) and their requirements (IRQ, DMA, memory.) using .NET > attributes. I would love to have drivers live inside of an inversion of > control container (HardwareResourceManager?), which wires them up and > provides them with all resources required. I would love to have a layered > design of drivers, similar to Microsoft WDM or even better: the newer > KMDF/UMDF - which would give us a couple of advantages. We're working on a driver design (it's in the Kernel/DriverSystem) and right now the drivers need to register themselves, but that's only because we don't have support for reflection within the kernel yet. The plan right now is to let the driver define an with attributes annotated interface, which will be used for drivers to describe themselves. The driver manager could then make an implementation using the interface, which the driver then can use. > 10. Power Management: I know this isn't the top priority, but from > experience I can tell you an OS needs to get this right from day one. It > takes a lot of effort to rewrite an OS, the apps and drivers to support > proper power management. SharpOS has a huge advantage: It doesn't have > "legacy" code to support. Its starting almost from scratch and should do its > best to support this. Are there any plans in this area? I agree that power management should be a central piece of the design of the kernel, but we haven't put much thought into it yet, so suggestions & ideas are welcome! :) > 12. Multithreading: What is the goal here for SharpOS? Provide unix-like a > process is a single thread or a Windows like a process consists of at least > one thread model? How far has work progressed there? The whole process model still has to be fully designed, but we'll have multiple threads per process. A process in sharpos will be mainly about ownership of resources (resources can't be owned by multiple processes) The scheduler will be pluggable at kernel load time to make experimentation with different schedulers easier. The whole threading part of the kernel is still under heavy development.. Most of us can be found on the IRC channel (#sharpos on irc.freenode.net).. usually you can find at least one of the board members (and at the very least some regular contributers) since we're spread across all time zones ;) Cheers, Sander van Rossen (aka logicalerror) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
