On Fri, Mar 14, 2008 at 8:21 PM, grover <[EMAIL PROTECTED]> wrote:
> 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.
>
These are definitely areas we could use some contributions in.
>
> 1. Are there any plans to support real plug&play (as far as it is
> possible)?
Definitely as much as possible.
2. Do you have any plans to support reflection in the kernel level?
Hell yea. And for the most part, we are there. We've just got a few dots to
connect first.
3. Is the kernel (and its drivers) going to be reentrant and thread safe?
They will.
> 4. Are you going to support checked channels (similarly to Singularity) to
> enforce proper usage of interfaces?
Like Sander said, we hope to make the connection as invisible as possible.
>
> 5. What kind of security model do you want to support (ACL or *nix-style?)
We actually haven't talked about it much - but it seems most of us are
leaning towards ACL.
>
> 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.)
>
Well, the Nash and Unix emulation stuff, are sort of un-official
sub-projects. We will use them and package them as much as possible, but
obviously we want to be innovative too. And we would love to have a full
implementation of something like PowerShell running on SharpOS, but it is a
massive undertaking, and is probably grounds for a whole project of its own.
>
> 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.
I'm one of the people that have been around here the longest, and I still
haven't had my own confusion cleared up on who wants what from the
filesystem. (At least we aren't bothering ourselves with stuff too far off.)
Sander is worried about the dirtyness of exposing stuff through a devfs type
of system, but depending on what we expose and how we control it, this could
be very powerful. (Think: ACLs for controlling the interface mechanism to a
node on the system - taking high priveleges to get a stream pointed at
something, and lower priveleges depending on how specific you are willing to
cast it.)
>
>
> 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.
>
There has been some talk about the system being self-aware of "installed"
software based on predefined installation locations. I'm not sure if I
follow this philosophy, because sometimes an installation process is a bit
more complex than xcopy-ing data around - but in the end, this should be
abstracted. And as a result, sometimes the only way for one app to interact
with the other will be to grab that named pipe from the "filesystem" and use
it.
>
> 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.
>
I don't know anything about the WDM, and especially not KMDF/UMDF - but
self-descriptive drivers are definitely something we want to move in the
direction of. Between reflection, and dynamic code generation, we have alot
to work with here.
>
> 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?
>
We haven't talked details about power management. And really, I personally
don't know anything about what it means to having power management thought
about from the beginning versus anything else - but I can tell you that we
have talked about being able to serialize an entire process's memory set,
and re-load it later, on the same, or even a different machine. So we are
definitely open to suggestions.
>
> 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?
>
I never really knew what the differences were, (other than the APIs
involved), but I think we will be going more in the direction of a process
being a container for one or more threads.
>
> 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.
>
>
Sorry about the slow response - I started typing this e-mail two days ago
and never got around to getting it done until now...
-Bruce
aka Illuminus
-------------------------------------------------------------------------
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
