Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : create a automagic device 'known' and attach all known devices from PNPBIOS : to it. Now _all_ pnp devices got their resources (even if there : is no driver for it) and attached to 'unknown' driver. Any kldloaded : driver later does not see t

Re: Reserving Resources

On Mon, Apr 03, 2000 at 09:11:10AM -0600, Warner Losh wrote: > You can't always disable PNP devices. More accurately, the devices > reported by PNPBIOS are defined to be hard wired and always active. > You cannot turn them off or relocate their resources. They likely > should be probed first ra

Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : On Mon, Apr 03, 2000 at 08:30:08AM -0600, Warner Losh wrote: : : > : I do not like the idea of resource consumation. Is there a : > : description of the problems which might arose without it? : > : > Machine deadlock, undetected irq conflic

Re: Reserving Resources

On Mon, Apr 03, 2000 at 08:30:08AM -0600, Warner Losh wrote: > : I do not like the idea of resource consumation. Is there a > : description of the problems which might arose without it? > > Machine deadlock, undetected irq conflict causing misbehavior, probing > hardware for device foo and lock

Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : I do not like the idea of resource consumation. Is there a : description of the problems which might arose without it? Machine deadlock, undetected irq conflict causing misbehavior, probing hardware for device foo and locking the machine be

Re: Reserving Resources

> H. This work was on a 4.0-RELEASE system Makes sense. Right, that has not backported yet. I'll do that ASAP (this evening), including the patch where nextunit is no longer used. > BTW, I have a hack to subr_bus that prints detach messages when a > device is detached. This will hoist

Re: Reserving Resources

> In theory, if one matches with a -1 or smaller rather than 0, then it > will be detached on reprobe. Isn't that the case? On -newbus this issue has come up and the conclusion was that there is always some problem rearing its ugly head. On loading a new driver you would have to run a non-intru

Re: Reserving Resources

> : The issue is pretty hairy and for now I think the solution is to make > : any stub use DEVICE_NOMATCH (see pci.c), which does not attach a driver > : to a device, just mentions it during boot. > > And during every reprobe after that... :-(. > I'm currently working on a pci card driver and th

Re: Reserving Resources

On Sun, Apr 02, 2000 at 02:29:55PM -0600, Warner Losh wrote: > The whole purpose of unknown is to CONSUME the resources that others > might try to use. This can't easily be done in the base bus w/o it > actually consuming them. Maybe we need a flag that means "I'm a > pseudo device that was cre

Re: Reserving Resources

In message Nick Hibma writes: : Um, in that case you should update subr_bus.c. Change committed two : weeks ago. I got annoyed to by that too :-) H. This work was on a 4.0-RELEASE system Makes sense. BTW, I have a hack to subr_bus tha

Re: Reserving Resources

In message Nick Hibma writes: : The issue is pretty hairy and for now I think the solution is to make : any stub use DEVICE_NOMATCH (see pci.c), which does not attach a driver : to a device, just mentions it during boot. And during every reprobe

Re: Reserving Resources

On Sun, Mar 26, 2000 at 10:42:40PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: > : I was wrong. 'unknown' driver attaches with (-100) priority. > : I have another problem -- when 'unknown' driver attached > : to my device, my kldloaded driver is not called at

Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : I was wrong. 'unknown' driver attaches with (-100) priority. : I have another problem -- when 'unknown' driver attached : to my device, my kldloaded driver is not called at all, so I can't : override 'unknown' with higher priority. So for a w

Re: Reserving Resources

On Sun, Mar 26, 2000 at 10:30:48PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: > : Current 'unknown' driver attaches with 0 priority, thus kldloaded > : driver is not called at all. And even when 'unknown' driver attaches > : with very low priority, what hap

Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : Current 'unknown' driver attaches with 0 priority, thus kldloaded : driver is not called at all. And even when 'unknown' driver attaches : with very low priority, what happens when real driver will be : kldunloaded? Hmmm. The unknown driver

Re: Reserving Resources

On Sun, Mar 26, 2000 at 10:18:49PM -0700, Warner Losh wrote: > : No good, because with current 'unknown' driver any kldloadable > : driver for pnp device would not get its resources. > > In theory, if one matches with a -1 or smaller rather than 0, then it > will be detached on reprobe. Isn't t

Re: Reserving Resources

In message <[EMAIL PROTECTED]> Nikolai Saoukh writes: : On Sun, Mar 26, 2000 at 04:40:53PM -0700, Warner Losh wrote: : : > First, I'll create a null driver. Let's call it "null" since : > "resourceplaceholder" is too long. This driver's probe routine would : > always succeed, and its attach rou

Re: Reserving Resources

On Sun, Mar 26, 2000 at 04:40:53PM -0700, Warner Losh wrote: > First, I'll create a null driver. Let's call it "null" since > "resourceplaceholder" is too long. This driver's probe routine would > always succeed, and its attach routine would gobble up all the > resources associated with this.

Reserving Resources

[[ moved from stable to hackers ]] dodd> Ah. So what we really want is some mechanism to tell the kernel 'hey, dodd> you! don't use this ioport/irq whatever.' (or otherwise mark some dodd> resources as not being available to PnP devices.) imp> I think that a null driver could easily be written