On Sat, Jul 26, 2008 at 5:25 AM, Phil Garcia <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 2:43 AM, grover <[EMAIL PROTECTED]> wrote: >> >> - AutoLoad: We should split this out entirely - I would like to see a more >> generic approach, where this is only a hint during installation. A seperate >> attribute, that specifies a default startup request - AutoStart, Demand, >> Disabled, ... Kind of like the Win32 service startup codes. However unlike >> Win32 I'd like to make this a request, e.g. during installation/first >> load/first start, the user should agree to this request. > > > Good idea. Is this the same as letting the run-time override the AutoLoad > setting?
I agree with grover that the driver should only provide defaults in this case and not having any say about if it's actually loaded or not. Personally i think we should divide types of assemblies into strict groups that have a certain set of limited capabilities. Like a driver could never start up any user interface code, and a normal application could never do any driver related stuff directly. This avoids people doing all kinds of weird or dangerous stuff without the user knowing it. But that's something for the future. >> I see that ISA is special, as we can't detect these devices easily, so >> maybe we should add a static method in those devices with the signature and >> a special Probing attribute: >> >> >> [ISAProbe] >> static bool Probe(); > > > I thought about this and decided to go with a non-static method for Probe(). > This way all hardware drivers follow the same life cycle: objection > creation-> setup() -> probe() -> start() -> createsubdevices() -> stop() -> > etc. Probe is just one part of it. Can't we just kill ISA? ...please? >> About the attribute class tree: This should make enumerating installed >> drivers easier, as there's only one run over all classes instead of one for >> each bus. > > I agree; I think this problem is solved by having a single DeviceManager > where all devices are registered with. "attribute class tree"? The reason i came up with with bus classes was that it would enable us to do bus specific things transparently, avoiding a monolithic device manager. But maybe we can work around that? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
