INTR_FILTER?
INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: INTR_FILTER?
on 29/01/2009 14:55 Ed Schouten said the following: > * Andriy Gapon wrote: >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > Not sure, but I think I was once told that FreeBSD has a `two level' > interrupt handling scheme, where the filter is invoked directly to only > figure out whether the interrupt is spurious or not. After it has been > determined it is not, an interrupt thread is scheduled to handle the > interrupt. > > But as I said, I'm not sure. :-) > This is true and is documented in bus_setup_intr(9). But INTR_FILTER is a compile-time kernel option. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: INTR_FILTER?
* Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect interrupt > code. Not sure, but I think I was once told that FreeBSD has a `two level' interrupt handling scheme, where the filter is invoked directly to only figure out whether the interrupt is spurious or not. After it has been determined it is not, an interrupt thread is scheduled to handle the interrupt. But as I said, I'm not sure. :-) -- Ed Schouten WWW: http://80386.nl/ pgpZnYO2BZE25.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Alexander Leidinger wrote: > So you want that either > - a daemon running as root is written which listens to user >requests to set the backlight via sysctl > or > - a SUID root program is written that sets the backlight >via sysctl > instead of > - a character device with appropriate filesystem permissions >which allows to not go the SUID root or daemon running as >root way > ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. The ideal solution would be to integrate it into vidcontrol, calling some kind of ioctl on the TTY/consolectl, but syscons is too brainless to know anything about hardware specific features. -- Ed Schouten WWW: http://80386.nl/ pgpMgbBaYMZZ3.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
Quoting Ed Schouten (from Wed, 28 Jan 2009 14:43:09 +0100): * Daniel Lannstrom wrote: > I'm asking which method will be the best to interface the driver with > userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Bye, Alexander. -- E.T. GO HOME!!! (And take your Smurfs with you.) http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: INTR_FILTER?
On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: INTR_FILTER?
on 29/01/2009 19:17 Rui Paulo said the following: > > On 29 Jan 2009, at 11:47, Andriy Gapon wrote: > >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > INTR_FILTER allows you to skip the FILTER+ITHREAD headache. Could you please explain a little bit what is this headache? I thought, similarly to what Ed said, that in filter one could quickly check for a stray interrupt (or shared interrupt from other device) and in ithread one could perform meaningful work. But I also had some doubts about what is legal and what is illegal in ithread. E.g. could I take a non-spin mutex or wait on a condvar? I guess not - because in the case of shared interrupts the same ithread is used to handle everything. > See dev/asmc/asmc.c for an example. Thank you, the example is enlightening. But also one has to look into how "the framework" works (or just know it) to understand why things are done this way but not the other. E.g. why you have to use a taskqueue in non-INTR_FILTER case. BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: critical floating point incompatibility
On 2009-Jan-28 11:24:21 -0800, Bakul Shah wrote: >On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds >32 bit binaries. The following script makes it as easy to do >so on a 64 bit FreeBSD -- at least on the few programs I >tried. Ideally the right magic needs to be folded in gcc's >builtin "specs". > >#!/bin/sh >args=/usr/bin/cc >while [ ".$1" != . ] >do >a=$1; shift >case $a in >-m32) args="$args -B/usr/lib32 -I/usr/include32 -m32";; >*) args="$args $a";; >esac >done >$args You also need to manually populate /usr/include32 since it doesn't exist by default and may still get bitten by stuff in /usr/local/include. Do you have a script (or installworld patches) to do this? amd64/112215 includes a first attempt at updating the gcc specs (though it's missing the include handling), as well as some of the remaining problems. >Ideally x86_64 platforms run *all* i386 programs (that don't >depend on a 32 bit kernel). Agreed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEBGdlUAosU.pgp Description: PGP signature
Re: INTR_FILTER?
On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
cc -m32 (was Re: critical floating point incompatibility
On Fri, 30 Jan 2009 05:44:00 +1100 Peter Jeremy wrote: > > On 2009-Jan-28 11:24:21 -0800, Bakul Shah wrote: > >On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds > >32 bit binaries. The following script makes it as easy to do > >so on a 64 bit FreeBSD -- at least on the few programs I > >tried. Ideally the right magic needs to be folded in gcc's > >builtin "specs". > > > >#!/bin/sh > >args=3D/usr/bin/cc > >while [ ".$1" !=3D . ] > >do > >a=3D$1; shift > >case $a in > >-m32) args=3D"$args -B/usr/lib32 -I/usr/include32 -m32";; > >*) args=3D"$args $a";; > >esac > >done > >$args > > You also need to manually populate /usr/include32 since it doesn't > exist by default and may still get bitten by stuff in > /usr/local/include. Do you have a script (or installworld patches) to > do this? Yes, includes for native programs will may cause trouble -- but you can't use -nostdinc (as that would take away that feature from a user), which is why this needs to be in the gcc specs. I don't have a script as I just copied include directories from a i386 system. But a script would be better. This script was an initial stab at proper -m32 support and needs more work. I will be happy to work with you or anyone else to make this happen. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: INTR_FILTER?
On 29 Jan 2009, at 17:51, Andriy Gapon wrote: on 29/01/2009 19:17 Rui Paulo said the following: On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. Could you please explain a little bit what is this headache? Basically, you use filter + ithread (intr_filter) when you want to do more than basic things in your interrupt handler routine. For example, allocating memory must be done in a ithread, it can't be done on the interrupt routine. I thought, similarly to what Ed said, that in filter one could quickly check for a stray interrupt (or shared interrupt from other device) and in ithread one could perform meaningful work. That's right. But INTR_FILTER does all the filter + ithread setup for you via FILTER_SCHEDULE_THREAD. But I also had some doubts about what is legal and what is illegal in ithread. E.g. could I take a non-spin mutex or wait on a condvar? I guess not - because in the case of shared interrupts the same ithread is used to handle everything. See dev/asmc/asmc.c for an example. Thank you, the example is enlightening. But also one has to look into how "the framework" works (or just know it) to understand why things are done this way but not the other. E.g. why you have to use a taskqueue in non-INTR_FILTER case. I needed a taskqueue because devctl_notify() calls malloc and you can't call malloc (which holds some type of lock, I can't remember) from an interrupt context (asmc_sms_intrfast()) BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? The drivers would have to be ported to INTR_FILTER. Right now, only asmc is using INTR_FILTER, so I don't think there is much gain in making it the default. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
