Putting artificial delays in a char driver
Hi All, I was fiddling around with an IR remote driver for my embedded platform to see if I can make the IR LED light (connected to GPIO's) blink on IR activity. The IR driver behaves like a char driver. The way to make the LED on/off is to simply write to some GPIO reg with a 1/0. So I was switching on the LED at the beginning of the function that reads data (in ISR context) and then switching it off at the end of that function. The problem was that all this happens too fats and I'm barely able to see the LED blink (there's only a faint flicker)! :) I tired various places in the driver to keep on/off calls as far as possible (ON in ISR and then OFF _after_ a copy_to_user()), but that did not help much. Whats the recommended way of solving this issue? I'm working on drivers after a really long time (last time I worked on a driver was when LDD 2nd ed was published!) so I'm not sure if bottom-halves or work-queues should be used. I was thinking what if I introduce an artificial delay in my driver where I sleep/wait for a few millsecs after switching on the LED and then switch it off after the incoming data has been processed. Is that a good idea? TIA, -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: unlocked_ioctl explanation
Thanks Dave for your answer. I guess the same question has been answered several times before. For the interest reader, I've found these: http://unix.stackexchange.com/questions/4711/what-is-the-difference-between-ioctl-unlocked-ioctl-and-compat-ioctl http://lwn.net/Articles/119652/ http://www.mail-archive.com/kernelnewbies@nl.linux.org/msg00269.html I have a remaining question, though. In the lwn article I read this: The ioctl() system call has long been out of favor among the kernel developers, who see it as a completely uncontrolled entry point into the kernel. Is this pointing that ioctl() is planning to get removed from the kernel ? In that case what's the currently preferred mechanism for giving 'control commands' to device drivers ? Thanks again and greetings, Ezequiel. --- El mié 18-may-11, Dave Hylands dhyla...@gmail.com escribió: De: Dave Hylands dhyla...@gmail.com Asunto: Re: unlocked_ioctl explanation Para: Ezequiel García elezegar...@yahoo.com.ar Cc: kernelnewbies@kernelnewbies.org Fecha: miércoles, 18 de mayo de 2011, 3:20 Hi Ezequiel, 2011/5/17 Ezequiel García elezegar...@yahoo.com.ar I am aware that ioctl has been superseeded by unlocked_ioctl. I've been looking through patches and this seems to be BKL related. Could someone explain further the differences and reasons for the new ioctl prototype and name? I guess 'unlocked' means BKL is no longer held inside ioctl, right? Exaclty. What precautions should we take when using unlocked_ioctl ? Well, since there is no BKL, your ioctl can get preempted by another process and that other process just might happen to make an ioctl call to your driver. So your driver has to protect itself from being called by 2 threads simultaneously, if that's a problem. Some drivers won't need any extra protection. Unfortunately, it really depends on exactly what your driver code does. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: unlocked_ioctl explanation
2011/5/19 Ezequiel García elezegar...@yahoo.com.ar Thanks Dave for your answer. I guess the same question has been answered several times before. For the interest reader, I've found these: http://unix.stackexchange.com/questions/4711/what-is-the-difference-between-ioctl-unlocked-ioctl-and-compat-ioctl http://lwn.net/Articles/119652/ http://www.mail-archive.com/kernelnewbies@nl.linux.org/msg00269.html I have a remaining question, though. In the lwn article I read this: The ioctl() system call has long been out of favor among the kernel developers, who see it as a completely uncontrolled entry point into the kernel. Is this pointing that ioctl() is planning to get removed from the kernel ? In that case what's the currently preferred mechanism for giving 'control commands' to device drivers ? I would bet for 'sysfs'. thanks, Daniel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: about 64-bits division in kernel
Hi lody, On Thu, May 19, 2011 at 8:34 PM, loody milo...@gmail.com wrote: hi all: My platform is 32-bits cpu and I need following calculation in my driver. #define longdiv(sr1, sr2, div) (unsigned long )unsigned long long)(sr1) 32) ^ (sr2)) / (div)) my question are: 1. why __udivdi3 has any relationship with above calculation? Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit division is not supported in all kernels. 2. I know the above calculation is implemented in clibc, but why kernel still implement itself? why kernel try to make another wheel instead of including what clib provided ? The kernel doesn't use anything from the C runtime library at all. 64-bit division and floating point are 2 things not supported in the kernel, although they do happen to word on some platforms, they aren't portable operations. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [Kgdb-bugreport] KGDB problem at first breakpoint
Enabling CONFIG_DEBUG_RODATA also didn't work. -Prabhu On Thu, May 19, 2011 at 6:45 AM, Dongdong Deng libfet...@gmail.com wrote: On Wed, May 18, 2011 at 7:23 PM, Prabhu nath gprabhun...@gmail.com wrote: Dear All, There is a problem with the KGDB at the very first break point after executing the gdb command target remote /dev/ttyS0 from the host. I have verbatim, followed the KGDB document http://kernel.org/pub/linux/kernel/people/jwessel/kdb/ Problem Logs: - Details of my hardware and system software: --- *Host (Development machine): * Intel Pentium IV Machine with Fedora Core 12 Linux Version : 2.6.31.5-127.fc12.i686.PAE gdb version : GNU gdb (GDB) Fedora (7.0-3.fc12) *Target:* Intel Pentium IV Machine with Fedora Core 12 Customized Linux Version : 2.6.38 Host is connected to Target via a null modem cable *Snapshot of .config of linux version 2.6.38 on the target * * * # CONFIG_DEBUG_RODATA is not set Hi Prabhu, The CONFIG_DEBUG_RODATA was suggested to set at KGDB, Could you enable it? CONFIG_DEBUG_RODATA = y Dongdong CONFIG_HAVE_ARCH_KGDB=y CONFIG_FRAME_POINTER=y CONFIG_DEBUG_INFO=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_LOW_LEVEL_TRAP=y *Grub config on the target machine* * * title Fedora (2.6.38) root (hd0,0) kernel /boot/vmlinuz-2.6.38 ro root=UUID=fb7800fb-cfe7-438d-bc7f-c153ba4353d1 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us*console=ttyS0,115200n8 kgdboc=ttyS0 kgdbwai*t initrd /boot/initrd-2.6.38.img On power on of the target, linux kernel boots and the logs are seen on the minicom console of the host and it will wait for the gdb on the host to connect. Here is the last 4 lines of the logs seen on the minicom Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A kgdb: Registered I/O driver kgdboc. kgdb: Waiting for connection from remote gdb.. *--- Now I close the minicom console (Ctrl-A X) and start the gdb on the host. Here is the steps I follow. * * * *On the host machine:* * * [root@localhost kgdb]# gdb vmlinux GNU gdb (GDB) Fedora (7.0-3.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /root/kgdb/vmlinux...done. (gdb) set remotebaud 115200 (gdb) set debug remote 1 (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Sending packet: $qSupported#37...Ack Packet received: Packet qSupported (supported-packets) is NOT supported Sending packet: $Hg0#df...Ack Packet received: OK Sending packet: $?#3f...Ack Packet received: S05 Sending packet: $Hc-1#09...Ack Packet received: OK Sending packet: $qC#b4...Ack Packet received: QC01 Sending packet: $qAttached#8f...Ack Packet received: Packet qAttached (query-attached) is NOT supported Sending packet: $qOffsets#4b...Ack Packet received: Sending packet: $g#67...Ack Packet received: 36000aba20d98bc06c3f86de783f86de803ac8dd803f86de885747c00202600068007b00c8dd7b0086de Sending packet: $mc0475788,1#a4...Ack Packet received: 0f Sending packet: $mc0475788,8#ab...Ack Packet received: 0faef889f6ff0d08 Sending packet: $mc0475788,7#aa...Ack Packet received: 0faef889f6ff0d 0xc0475788 in ?? () Sending packet: $qSymbol::#5b...Ack Packet received: Packet qSymbol (symbol-lookup) is NOT supported (gdb) s Cannot find bounds of current function (gdb) *Observation:* *1.* Ideally the kernel being debugged should break at legitimate address and the corresponding line number should be displayed instead of 0xc0475788 in ?? (). 2. On inspecting section header in vmlinux executable, I found the .text section address range is from 0xC100 to 0xC1326e58 and no section's contents associate with the address 0xC0475788. *3.* Hence on single stepping, gdb logs the error as* Cannot find bounds of current function* * * Humbly request you to help me in addressing this issue. Thanks and Regards, Prabhu
LSM skeleton module printk message not showing in dmesg
Hi All,
I am writing a skeleton LSM module to only print the message at boot time,
but I could not see any printk message in the dmesg.
Below are steps i did to enable the printk messages in the LSM module.
What i did is download linux kernel 2.6.33.3.
1) added the line source security/lsmcustommod/Kconfigin
linuxsrc/security/Kconfig near ima/Kconfig.
2) added subdir-$(CONFIG_SECURITY_LSMCUSTOMMOD) += lsmcustommod
line at linuxsrc/security/Makefile
3) created a directory in linuxsrc/security/lsmcustommod and putted three
files
i) lsmcustommod.c
ii) Kconfig
iii) Makefile
*Kconfig file contents*
config SECURITY_LSMCUSTOMMOD
bool LSMCUSTOMMOD Support
depends on SECURITY
select NETWORK_SECMARK
default n
help
*Makefile Contents*
obj-$(CONFIG_SECURITY_LSMCUSTOMMOD) := lsmcustommod.o
*lsmcustommod.c* contents
static __init lsmcustommod_init(void){
/* register the hooks */
if (register_security(lsmcustommod_ops))
panic(lsmcustommod: Unable to register lsmcustommod with
kernel.\n);
else
printk(lsmcustommod: registered with the kernel\n);
return 0;
}
static void __exit lsmcustommod_exit (void)
{
return;
}
module_init (lsmcustommod_init);
module_exit (lsmcustommod_exit);
MODULE_DESCRIPTION(lsmcustommod);
MODULE_LICENSE(GPL);
#endif /* CONFIG_SECURITY_LSMCUSTOMMOD */
After that I also added some return 0 and printk statments in the
lsmcustommod_ops stucture.
lastly disabled all modules in make menuconfig and select LSMCUTOMMOD in
security sections of the menufile and compile the kernel by the following
command.
make make modules make modules_install make install
updategrub2
--
Toqeer Ali Syed
Red Hat Certified Engineer
mob: +60166205504
mob: +92 321 9059916
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: about 64-bits division in kernel
hi Dave: Thanks for your kind reply. 2011/5/20 Dave Hylands dhyla...@gmail.com: Hi lody, On Thu, May 19, 2011 at 8:34 PM, loody milo...@gmail.com wrote: hi all: My platform is 32-bits cpu and I need following calculation in my driver. #define longdiv(sr1, sr2, div) (unsigned long )unsigned long long)(sr1) 32) ^ (sr2)) / (div)) my question are: 1. why __udivdi3 has any relationship with above calculation? Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit division is not supported in all kernels. why the name __udivdi3 has relation to 64-bits arighmetic? Why linker ask for __udivdi3, it seems there is a common sense for linker that when doing 64-bits calculation it will try to find __udivdi3, am i right? 2. I know the above calculation is implemented in clibc, but why kernel still implement itself? why kernel try to make another wheel instead of including what clib provided ? The kernel doesn't use anything from the C runtime library at all. 64-bit division and floating point are 2 things not supported in the kernel, although they do happen to word on some platforms, they aren't portable operations. the 64-bit division seem supported in gcc toolchain, and gcc will take care the platform issue when we cross-compile the gcc, right? It should be safe to static link the 64bits division in gcc. -- Regards, ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
