put a message and wait a key on kernel boot
i am trying to put a message editing the file ¨e820.c¨ to put i use printk(), but i dont know how do for wait until the user press a key ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
FIQ support in Linux Kernel
Intro: basically, I tried to post this question to
linux-arm-kernel-requ...@lists.arm.linux.org.uk, but the email just
fails to reach the server or something... :-(
Following the FIQ disscussion here:
http://www.spinics.net/lists/arm-kernel/msg14959.html
and here:
/*=
* Undefined FIQs
*-
* Enter in FIQ mode, spsr = ANY CPSR, lr = ANY PC
* MUST PRESERVE SVC SPSR, but need to switch to SVC mode to show our msg.
* Basically to switch modes, we *HAVE* to clobber one register... brain
* damage alert! I don't think that we can execute any code in here in any
* other mode than FIQ... Ok you can switch to another mode, but you can't
* get out of that mode without clobbering one register.
*
* Fast Interrupt dispatcher
* Enter in FIQ mode, spsr = SVC/USR/IRQ/dABT CPSR, lr = SVC/USR/IRQ/dABT PC
*/
Subject: Linux crashes with FIQs enabled
From: li...@arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 15 Aug 2003 18:00:33 +0100
In-reply-to: 007201c3634c$2b61cd40$3f00a...@geomation.com; from
registrat...@junck.com on Fri, Aug 15, 2003 at 10:42:03AM -0600
References: 007201c3634c$2b61cd40$3f00a...@geomation.com
It looks like you failed to read my comments above - this may be why
you're seeing the occasional problem.
Think what happens when you've just entered SVC mode (eg, due to a SWI) and
you haven't saved any state. The previous context is saved in SPSR_svc,
and the processor has disabled IRQs for you, but not FIQs.
You take a FIQ from SVC mode before you've saved any state. The SVC-mode
CPSR gets saved in SPSR_fiq. What about SPSR_svc? How are you saving/
restoring that? (you aren't, and you can't if you switch out of FIQ mode.)
This is the fundamental problem with the approach of treating FIQs as if
they were IRQs. They aren't the same because the processor doesn't give
the same guarantees.
Does Basically to switch modes, we *HAVE* to clobber one register
mean that to switch
processor mode we _must_ use movs pc, lr or ldmia sp, {r0-pc}^
instruction only?
I mean, those instructions demand SPSR_current to be clobbered
(that is SPSR_current's control bits M[4:0] should be equal to the
next processor mode)
before executing the instruction.
Is there any other problematic scenario except this:
1) USR mode (syscall)
2) SVC[1] mode (before any instruction is executed)
3) FIQ mode (save r0, spsr and lr through 'vector_stub fiq...')
4) SVC[2] mode (take care of FIQ stuff and get back through movs
pc, lr to previous mode)
5) SVC[1] mode :-( but SPSR_svc is clobbered in the previous step
due to movs pc, lr:-( :-( :-(
I am aware of fiq-engine by Alessandro Rubini that runs FIQ exception
handler in FIQ processor mode only:
vector_fiq:
- disable_fiq
+ ldr r9, 1f
+ ldr r9, [r9]
+ movsr9, r9
+ beq fiq_ret
+ mov r8, lr
+ mov lr, pc
+ mov pc, r9 /* jump to userptr */
+ mov lr, r8
+fiq_ret:
subspc, lr, #4
Just trying to understand the interesting stuff...
Any feedback is *greatly* appreciated!!
Thanks,
--- Kosta
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Generic I/O
I'm finding it's really simple to write generic I/O functions for block devices (via a struct block_device) to mimic the posix read() and write() functions (I have to supply the position, since I don't have a fd to keep a position for me, but that's perfectly ok). I've got a little hack that allows me to run synchronously or asynchronously, relying on submit_bio() to create the threads for me. My caller function has an atomic_t value that I set equal to the number of bios I want to submit. Then I pass a pointer to that atomic_t around to each of the bios which decrement it in the endio function for that bio. Then the caller does this: while(atomic_read(numbios) 0) msleep(1); I'm finding the msleep(1) is a really really really long time, relatively. It seems to work ok if I just have an empty loop, but it also seems to me like I'm re-inventing a wheel here. Are there mechanisms that are better suited for waiting for tasks to complete? Or even for generic block I/O functions? -Kai Meyer ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: contribute to linux kernel
On Mon, Nov 14, 2011 at 05:35:38PM -0500, Mayank Agarwal wrote: Hi all, I have just joined the kernelnewbies.I want to contribute to linux kernel or to any of the open source ongoing projects.Has good experience in c,c++ and linux programming. Please suggest how can i go about that. Please read Documentation/HOWTO ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Locking IOCTL
Hi Praveen,
On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar chatpr...@gmail.com wrote:
Hi All,
I have a situation where I have to lock the ioctl provided in my driver. I
have a uni processor (ARM) system.
I am using Mutex as the lock for my ioctl.
DEFINE_MUTEX(lock_ioctl);
MyIoctl()
{
Mutex_lock(lock_ioctl);
Switch(){
...
}
Mutex_unlock(lock_ioctl);
return 0;
}
I just wanted to know am I using the best lock available for the situation
aor do I have any flaw in my implementation???
And from LKD I read that *lock the data not the code* and which I am
literally doing so ?? any comments on this ?
By creatiing something called lock_ioctl, I'd say you're locking the code.
Locking the data means that lets suppose you have some data structure
which requires mutual exclusion. Then I'd create a lock associated
with that data structure (and probably the lock would be a member of
the data structure), and anytime I needed to manipulate/access the
data structure (in an atomic manner), I'd acquire the lock.
I have interrupts in my driver which is nothing to do with the lock.I am
taking care that where ever I return in my ioctl the lock is released.
What are you locking? Does every single ioctl really need to acquire
the lock? Why?
--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
