Date: Fri, 28 Oct 2005 10:37:09 -0600 (MDT) From: Warner Losh <imp@bsdimp.com> To: glebius@freebsd.org Cc: src-committers@freebsd.org, jhb@freebsd.org, peter@wemm.org, cvs-src@freebsd.org, cvs-all@freebsd.org, linimon@lonesome.com Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c src/sys/alpha/isa isa.c src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/amd64/isa atpic.c src/sys/arm/arm intr.c src/sys/dev/sio sio.c src/sys/dev/uart uart_kbd_sun.c uart_tty.c ... Message-ID: <20051028.103709.74689710.imp@bsdimp.com> In-Reply-To: <20051028160218.GJ41520@cell.sick.ru> References: <200510261648.27126.peter@wemm.org> <200510281041.44147.jhb@freebsd.org> <20051028160218.GJ41520@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Gleb Smirnoff <glebius@freebsd.org> Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c src/sys/alpha/isa isa.c src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/amd64/isa atpic.c src/sys/arm/arm intr.c src/sys/dev/sio sio.c src/sys/dev/uart uart_kbd_sun.c uart_tty.c ... Date: Fri, 28 Oct 2005 20:02:18 +0400 > John, > > On Fri, Oct 28, 2005 at 10:41:42AM -0400, John Baldwin wrote: > J> > Of course the real challenge is to make things like the puc device do > J> > the right thing automatically instead of needing 'options > J> > PUC_FASTINTR'. > J> > J> You mean like sio(4) tried to? The problem is that with the previosu code if > J> sio(4) went first, it would register INTR_FAST and some later PCI device > J> wouldn't be able to register its interrupt. There's not an easy solution to > J> that problem if you want to keep the semantics that INTR_FAST implies > J> INTR_EXCL. > > is it possible to implement such a feature that driver requests INTR_FAST > and it succeds only and only if interrupt isn't shared? Not really. The problem is that you don't know it is shared until it is too late. You have no way of really knowing if a device uses interrupts until its driver attaches and requests an interrupt. Given how we do our device probing, there's not really a chance to 'downgrade' the FAST to non-FAST later with driver notification (we can trivially downgrade what we do to ithread, but then the driver might not actually work). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028.103709.74689710.imp>