Message-ID: <Pine.LNX.4.61.0809121035390.7493@chaos.analogic.com>
Date:	Fri, 12 Sep 2008 10:45:43 -0400
From:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
To:	"emin ak" <eminak71@...il.com>
Cc:	"Linux kernel" <linux-kernel@...r.kernel.org>
Subject: Re: Building Kernel with -O0


On Fri, 12 Sep 2008, linux-os (Dick Johnson) wrote:

>
> On Fri, 12 Sep 2008, emin ak wrote:
>
>> 2008/9/10 Bodo Eggert <7eggert@....de>:
>>> linux-os (Dick Johnson) <linux-os@...logic.com> wrote:
>>>
>>>> If you have to single-step through kernel procedures, you
>>>> are not writing proper code for a kernel. Furthermore, even
>>>> when using the kernel debugger, you are not executing the
>>>> exact same path that would be executed without the debugger
>>>> attached.
>>>
>>> I sometimes single-step in order to verify my (userspace) code, instead of
>>> just throwing random test data at it. It's easier and makes me feel better.
>>> OTOH, -O2 never was a problem if I used it, so I don't strongly vote
>>> for enabling -O0.
>>>

Let me steal a bit of bandwidth and explain what
I mean about writing kernel code.

What is often lost to new people who want to develop
kernel code is that you can write and test many
pieces of kernel code within a "friendly" user-mode
environment.

Suppose you need to write a driver for a complex
I/O subsystem that is accessed over the PCI bus.

This seems difficult until you understand that the
starting piece of code will be something to find
your device and access its registers. This can
usually be (mostly) copied from another existing
driver.

Once its memory-mapped registers have been
uncovered, you can implement mmap() in your
driver and then access them from a user-space
program you write, reading/writing setting
bits and observing the hardware behavior
well before you write actual driver code.
Parts of the code that you develop in user-
space will eventually be cut and pasted
into your kernel driver code.

You are not going to be able to write your
interrupt service routines in user-mode but
they can still be in your driver code in which
you implemented mmap(). They just do a printk()
and attempt to reset your hardware for the next
interrupt. If it doesn't work, you can experiment
in user-mode, writing to registers, until you
have satisfied the hardware so the next interrupt
will properly occur.

If you write drivers in this manner, you will not
have code that doesn't work in the kernel code. It
may not work exactly as you want, but it will work
well enough so that a few printks will allow you
to get its real-time operation working as expected.

Warning! Do NOT leave hardware registers exposed to
user-mode access like Windows does. Your initial memory-
mapping was to help develop kernel code, not to create
a user-mode driver! Such code would be called a "layering
violation..."


Cheers,
Dick Johnson
Penguin : Linux version 2.6.25.17 on an i686 machine (4786.38 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@...logic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists