Not yet a formal developer, but I'm working my way there. And since some of
my own thoughts are touched by your questions, I'll try and provide some
answers.
2. I believe so yes. But I'd rather let the more experienced devs provide
the details.
3. Lock support is incomplete, which is why the code currently isn't
multithread safe. I'm actually looking at using atomic processor
instructions in the parts I'm working on to avoid locks as much as possible
but still remain multithread safe and improve performance. But it will be
multithread safe in the future.
6. I also suggested such a thing, though at the moment it's more of a "if
you want it, code it" thing with the shell.
8. I had some thoughts regarding filesystems, such as taking the model used
in GoboLinux (every app is its own folder) and expanding on that by taking
advantage of the database like features something like BFS provides. But
that's still a long way down the road.
Others, I'll leave to the real developers to answer.
On Fri, Mar 14, 2008 at 7:21 PM, 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. It looks like an
> incredible effort and I think I can help a bit or two. About myself: I'm
> almost 30, have been developing (system) software for almost 18 years now
> and have a lot of experience in embedded software systems, e.g. good
> designs, performance and power are fields where I should be able to help.
>
> Reading through the docs I have a couple of questions/issues I'd like to
> discuss. Some of these questions do not apply to the current state, but
> will
> apply in the future. Some of them apply to the current codebase.
>
> Questions I haven't found answers for:
>
> 1. Are there any plans to support real plug&play (as far as it is
> possible)?
> 2. Do you have any plans to support reflection in the kernel level?
> 3. Is the kernel (and its drivers) going to be reentrant and thread safe?
> 4. Are you going to support checked channels (similarly to Singularity) to
> enforce proper usage of interfaces?
> 5. What kind of security model do you want to support (ACL or *nix-style?)
>
> Questions regarding design choices or ideas:
>
> 6. You are developing a new IL based shell for SharpOS, but why are you
> reimplementing bash (Nash) and the unix toolset? Shouldn't SharpOS use an
> object oriented shell similar to PowerShell? I think it would be more
> appropriate and enable a lot more options in combination with a modern
> file
> system (next points.)
>
> 7. On the wiki you are specifying that you do not want to provide a
> *nix-like /dev filesystem? Why is that? I think that the /dev and /proc
> filesystems are an accomplishment, which we should not drop. My take on it
> is this: A plug&play manager enlists all found device (objects) in the
> /dev
> filesystem and a (PowerShell-)Script could use these entries to access the
> drivers directly (through a proxy/stub) - using a predefined object
> oriented
> interface provided by the driver. This would allow advanced scenarios,
> which
> are possible on *nix, but not possible on Windows - except we'd support
> this
> using OO. No more block and character devices. The filesystem should serve
> two things: A global namespace for objects (a simple byte stream file just
> being a System.IO.Stream...) and a way for things to interact and
> synchronize.
>
> 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.
>
> 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.
>
> 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?
>
> 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?
>
> That's it for now. I'm sure more will follow as I get my head more around
> the current code/possibilities. I hope I'm not asking the wrong questions
> or
> stuff that's been discussed already.
>
> Mike
>
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
