Date: Sun, 26 Mar 2000 16:40:53 -0700 From: Warner Losh <imp@village.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: winter@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Reserving Resources Message-ID: <200003262340.QAA87438@harmony.village.org> In-Reply-To: Your message of "Sun, 26 Mar 2000 21:49:13 %2B0900." <200003261249.VAA05285@tasogare.imasy.or.jp> References: <200003261249.VAA05285@tasogare.imasy.or.jp> <200003260112.SAA76635@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ 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. imp> I also think that combined with the hint mechanism I posted to new-bus imp> a couple of days ago this could be a viable way to reserve interrupts imp> from the boot loader. Iwasaki-san then replied: : That would be good. I'm also having similer idea that loading kernel : loadable module for legacy non-PnP devices specifying thier resources, like; : : load pcm : load sbc port 0x220 irq 5 drq 1 flags 0x15 : : Or, null driver module maybe just enough to hold resources; : load resourceholder port 0x220 irq 5 drq 1 : load resourceholder port drq 5 : : # BTW, it seems that the discussion is away from ep driver and -stable already :) : # Should we move to somewhere? Here's what I'll be happy to do. 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. Very much like the unknown driver does for pnp resources today. Maybe it would even have an identify routine that would go looking for hints for each null device and then attach the null children to the right place in the tree (likely the nexus, but I haven't thought through all the implications of doing this). Second, I'll create the hint driver. The hint driver is attached to the nexus and allows one to aribitrarily set hints for other drivers. The drivers are free to ignore these hints, of course, but the mechanism is generic. Alternatively, we could just make it run early in the boot process. So, to reserve irq 5 because it has real hardware that we don't have a driver for, one could add device null0 at nexus? irq 5 to the config line of your kernel. Alternatively, you could add the following in your boot environment: hint.null.0.irq=5 hint.null.1.irq=15 hint.null.1.iobase=0x330 hint.null.1.iolen=16 and these resources would be unavailable for other purposes. I'm not quite sure about the syntax for these variables, but you get the idea. I'm also not sure how to handle multiple rids, etc. The code for the hint driver has been written. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003262340.QAA87438>