..Sounds a lot like the designs/ starting implementation that i already wrote ;)
On Feb 4, 2008 1:33 AM, Bruce Markham <[EMAIL PROTECTED]> wrote: > ... So in the end, we need to agree more on our process > than our approach - because we will probably end up completely refactoring a > few times. (And there are design decisions that in-and-of themselves, can > make this easier - like interface versioning.) i agree, but it'll help to keep things as abstract as possible > As I understand it, some things work the same everywhere - like PCI. And > some things don't - like writing to I/O ports. So we need an abstraction > that can handle at least most kinds of allocatable/reservable hardware > resources. The current idea which has already been discussed on the irc channel a couple of times is that we'll eventually use reflection to help out with this.. A driver would create an interface and annotate it with attributes (stuff like driver signature so it can be matched to a device by the DriverManager, and what io ports it uses etc.) The driver would then pass this interface to the HardwareResourceManager which then uses the annotated interface to determine if the specified hardware resources are available (or even exist on the current system), and if everything is in order it'll reserve those resources for the driver and implement a class inheriting from that interface using reflection. There are a couple of advantages of doing this, like for instance that the driver wouldn't have to be written against a specific architectures' hardwareresourcemanager.. Right now obviously we don't have any reflection or JIT yet, so right now we'll just hardcode it.. > The abstraction needs to address which devices have which > resources, which devices *need* which resources, how to resolve them both, > and how to gracefully handle a failed attempt at such. This part hasn't been discussed much on the irc channel, so this is definitely something that needs to be thought out. There are obviously going to be several levels of failure.. If a driver requests resources which are already in use, the driver obviously can't be loaded, driver is disabled and that's pretty much it.. If a driver fails during execution is a completely different matter.. We could raise an exception and notify all processes which communicate with this driver i suppose. Maybe try to reset/restart it a couple of times.. Or replace it with another generic driver if available.. > Another issue, is device discovery and driver inter-dependencies. The current idea for device discovery is that the architecture defines a couple of predefined devices & their drivers (basic drivers such as PCI), and when the devicemanager is started it'll go trough the list to see if they're available. These devices can then be checked if they have other devices attached to them. The DriverManager can then be checked if a driver can be found that matches the signature of each device. Inter dependencies is a complicated problem where we haven't found a good solution for yet. > On-board system devices, if exposed, need to be exposed abstractly - > including the PIT, the interrupt table, and any other motherboard/CPU > capability that is detectable programmatically. Well the PIT is really a hardware resource, i don't think it should be exposed at all. It would simply be a hardware resource that's managed by the hardwareresourcemanager. > And last but foremost, we need to make everything "safe". That means drivers > will not be using pointers, nor I/O ports, directly. My best suggestion is > to wrap anything with an inherent write or read paradigm, as a stream. An > I/O port stream wraps ADC I/O port functionality. A memory buffer stream > (akin or maybe identical to, or replacing, a MemoryStream) wraps a pointer > and any ADC/Assembler functions available for fast memory writing. We actually need several different types, some are read-only, some are write-only, some can be read from and written to. There are other issues such as that some hardware only can be written to using 8-bit ports while other hardware can be written to using 32 bit ports. (this could be handled transparently) So i think we actually need multiple wrappers since it's better to catch invalid usage at compile time rather then throwing an exception at runtime. We might also want the JIT compiler to inline the methods of these wrappers.. We already have a memorymap (going to be renamed to memorybuffer) class which safely wraps memory blocks that are used by some drivers (think video memory / dma) > This is where our power, yet safety, comes from. An example benefit is, when > we start talking about distributed usage of hardware - we could literally > run a driver on one machine against the raw hardware of another - by > marshalling the stream operations. (Would it not be good for debugging?) Debugging is a really interesting point, i haven't thought of that, but having abstract hardware usage we can easily put a debugging layer in between when we want to debug a driver.. that could be *very* usefull > Other "safe"ty issues involve using things like delegates, exceptions, etc., > to fully leverage the runtime's power. > Some other miscellaneous food for thought: > ADC is not hardware. ADC should be dumbed down as much as possible - and > the namespaces should be completely seperate. SharpOS.Kernel.ADC & > SharpOS.Kernel.Hardware , or something along those lines. Yes i've started to notice the limitations of the current structure as well.. Maybe the AOT could be changed so that we can be more flexible in this regard, so that the whole concept of, for example, an ADC isn't so much tied to the AOT. > Examples of ADC: > Copying chunks of memory using Assembler instructions We could implement the Buffer class in .net 2.0 for this. We already have a class MemoryUtil which has several memory block functions (copy / fill) > Reading CPUID and returning bitmasks (represented by masked enum values) of > its features (or a nicer abstraction of boolean properties) The processor class already uses enums internally to make the code readable, but it returns the flags as strings using a wrapper class.. (the idea is that we might need to put in more functionality later? strings might be enough by itself) The thing is, these flags don't make much sense outside the ADC (in hardware independent land) unless it's to display information about the current processor. > Reading and writing to I/O ports > Assigning/changing interrupt handlers These 2 should be assigned by the hardwareresourcemanager and wrapped by several types of class (& delegates?) and not directly accessible trough the ADC imho. > Determining the cursor location on the text-mode screen > Writing color codes and ASCII characters to the text-mode screen Shouldn't textmode be a driver? not really platform independent either, mobile devices don't have textmode, pc's will eventually have uefi support which will radically change textmode (unicode) > Retrieving multiboot information We had a discussion about that on irc, multiboot is not platform independent.. there are plenty of platforms which wouldn't need a bootloader (handheld devices) I'm not necesarily saying that we need to move this to the ADC -right now-, but it's definitely something we need to think about. > Examples of "Hardware" or kernel functions that are otherwise *not* ADC: > Interrupt handling (because they are being handled by objects designed to do > so) > Providing and tracking output to the screen > Writing to the serial port What do you have in mind here then? putting it in a driver? On the one hand it makes sense, on the other hand we're using the serial port for debugging of the kernel, so we might need to handle this as a special case and not necesarily put it in a driver? > Task scheduling > Enumerating PCI devices This would be done by a pci driver. > A good example of "not ADC" is memory allocation. This is more of a runtime > issue. Sure, it has to figure out how much RAM is available - which is > architecture-dependent. But the actual allocation, and tracking of > allocations, is as generic as it gets. > Basically, its only ADC if it is a static function. And ADC should *only* be > static functions, for performance reasons. I don't necesarily agree with this, not all functionality is performance critical. > My assumption is, if for some reason, you need local context information to > handle an incoming function > call, then you are doing something that *in general* is not > architecture-specific. > And since static method calls are quicker than VTable lookups, we need to > keep our abstractions in check. > Constant vigilance! Well it certainly would help if we divide the kernel up into certain sections such as ADC and that we have strict definitions of what it is for, what is allowed etc. Especially considering it'll have to be re-implemented for different architectures. > Another miscellaneous food for thought is pointer usage. If you are writing > code against the architecture, or against memory, that requires the > representation of a memory address: we need to stop using 'uint' just > because we are assuming we are working on 32-bit x86. " void* " exists for a > reason... Good point, i think we need to make some adjustments in some AOT stubs as well. > Just because we want to use IPC for drivers doesn't mean we *should* anytime > soon. Any good marshalling IPC scheme should be pretty seamless anyway, and > it is more important for us to get hardware stuff of the ground. > And no matter what, for debugging purposes, we need to retain > static-buffer-based string operations and screen/serial I/O - so that if > something gets horribly screwed up, we can figure out what's going on. Maybe we need two implementations of textmode, one for startup, one for a proper textmode driver once the kernel is intialized. Perhaps they can both use the same functions internally. ------------------------------------------------------------------------- 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
