I like the idea with the properties as well. But I would suggest not to go that path but rather to use a Hardware Resource Manager.
For example the VGA driver should not and needs not access the DMA or ports that are specific to query the PCI. With the Hardware Resource Manager it would be easier to control what a driver is allowed to do and not to do. And not the other way. So when a driver needs some ports it asks the Hardware Resource Manager if it is allowed to access it. Chriss. Sander van Rossen wrote: > On Dec 27, 2007 7:56 AM, Bruce Markham <[EMAIL PROTECTED]> wrote: > >> That, my friend, is a really slick idea. >> > > Well i can't take full credit for the idea since singularity does > something simular (on the language level, they have a modified version > of C#) > The idea to use properties like this is mine though (and i'm not a > 100% sure if it's a good idea, because it looks like a field now, even > though it's really an IO port.. it looks 'clean' and readable though) > > > > >> But I'm wondering... >> >> I've been working with PCI. And PCI you use an out() to one port, and then >> an in() from another, to read configuration data. >> >> The parameters written to the first port determine from which PCI >> configuration "registers" (and on which devices), that the read from the >> second port returns. Can you define better how that would match your >> abstraction? >> > > I'm not exactly sure what you mean here... > but the only reason i implemented only one get and one set per > property is because those ports in the example only read or write.. > there's no reason why a port wouldn't be able to read and write > (get/set) > In fact, i see no reason why we couldn't have some sort of symantic > that would allow you to have a different port for the get and the set > of the property.. > > There would be attributes for 'fixed' IO ports & memory, for older > hardware, and other attributes for dynamically allocatable IO ports > and memory.. > > Other than that, i haven't dived into pci specifics yet, so if i > misunderstood you'll have to elaborate.. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > 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 2005. 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
