Peter Zijlstra wrote:
> No indeed. You seem confused with remaining and new.
>
> It has one VMA (A) it needs to split that into two pieces, it happens to
> do it like (B,A') where A' is the old VMA object with new a start
> address, and B is a new VMA object.
Is there any rules to decide which V
Peter Zijlstra wrote:
> On Fri, 2006-11-17 at 12:50 +0000, moreau francis wrote:
>>
>> lower vma: 0x2aaae000 -> 0x2aaaf000
>> upper vma: 0x2aaaf000 -> 0x2aab2000
>
> that is the remaining VMA, not the new one; we trigger this code:
>
> /* Does it split
Peter Zijlstra wrote:
>
> http://lwn.net/Kernel/LDD3/
>
> Chapter 15. Section 'Virtual Memory Areas'.
>
> Basically; vm_ops->open() is not called on the first vma. With this
> munmap() you split the area in two, and it so happens the new vma is the
> lower one.
>
since I did "munmap(0x2aaae000
Hmm, I'm probably missing something but I don't see what. Please be
nice even if the question is really stupid ;)
I'm looking at mmap.c code and to understand it I decided to implement
a dumb char device that implement its own foo_mmap() method. In this
method it defined its own vma ops:
stat
--- Andy Isaacson <[EMAIL PROTECTED]> a écrit :
>
> Did you *read* the post?
>
> # The _only_ acceptable use of "volatile" is basically:
> #
> # - in _code_ (not data structures), where we might mark a place as making
> # a special type of access. For example, in the PCI MMIO read functions,
--- Andy Isaacson <[EMAIL PROTECTED]> a écrit :
>
> The first register write will be completed before the second register
> write because you use writel, which is defined to have the semantics you
> want. (It uses a platform-specific method to guarantee this, possibly
> "volatile" or "asm("eiei
--- "linux-os (Dick Johnson)" <[EMAIL PROTECTED]> a écrit :
>
> On Wed, 24 Aug 2005, moreau francis wrote:
>
> > Hi,
> >
> > I'm currently trying to write a USB driver for Linux. The device must be
> > configured by writing some values int
Hi,
I'm currently trying to write a USB driver for Linux. The device must be
configured by writing some values into the same register but I want to be
sure that the writing order is respected by either the compiler and the cpu.
For example, here is a bit of driver's code:
"""
#include
static i
--- Vojtech Pavlik <[EMAIL PROTECTED]> a écrit :
> >
> > I can't find "pinpad/input0" in sysfs, does that mean I need to add sysfs
> > suppport in my driver, and it's not done in input module when I register
> > my input driver ?
>
> I'm sorry, I thought it's already in mainline, but that bit i
Thanks Vojtech for your answers !
--- Vojtech Pavlik <[EMAIL PROTECTED]> a écrit :
> It's also available via an ioctl() and in sysfs. This allows you to
> specify in an application that you want a device plugged into a specific
> port of the machine. Not many applications can use it at the moment
hello,
--- Vojtech Pavlik <[EMAIL PROTECTED]> a écrit :
> > What is this field for ?
>
> It is intended for identifying the device based on "location" in the
> system.
>
hmm, sorry but I don't understand you. I initialised this field with
"pinpad/input0" but the only place I can grep or find
Hi,
I'm currently developping a very simple driver for a pinpad by using
Input module. I'm using Event handler to pass events from pinpad to userland.
In this simple case, I'm wondering if I really need to initialise
"phys" field in in "input_dev" struct before calling "input_register_device".
Wha
Pekka J Enberg wrote:
> Hi Willy,
> Willy Tarreau writes:
>
>> I dont agree with you here : enums are good to simply specify an ordering.
>> But they must not be used to specify static mapping. Eg: if REG4 *must* be
>> equal to BASE+4, you should not use enums, otherwise it will render the
>> code
--- Russell King <[EMAIL PROTECTED]> wrote:
> If you want it to be immediate, then I'm afraid
> you're going to have a
> relatively hard time, with compatibility problems
> with various systems.
> You can't really dictate to people that they must
> turn off the FIFOs on
> their UARTs for your prod
Russell King wrote:
>I, therefore, strongly suggest that you arrange to do
the same - iow,
>deassert RTS when your buffer is approaching approx.
2/3 full rather
>than absolutely full.
Well, I don't think this gonna work because my rx fifo
is only 8 bytes
length and 8250's one is 16 bytes length. T
I tried to use my serial port with rts/cts flow
control enabled in order to transfer a data file
between 2 DTE. The first one is a PC running Linux
with a 8250 UART and the second one is a developement
board running Linux with a particular UART (I wrote
its driver based on 8250's one).
Actually
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> moreau francis <[EMAIL PROTECTED]> wrote:
>
> How does this look?
>
It works well though I haven't tested the second
correction. But it looks good...
By the way, is it safe in "n_tty_receive_overrun" to
ca
I noticed that TTY is not able to notify overrun issue
in "n_tty_receive_overrun". Actually it's because of
"time_before" macro which tests "tty->overrun_time"
(equals to 0) against "jiffies - HZ" (something very
big
after booting).
I guess a simple way to solve it, is to initialize
"tty->overrun_
18 matches
Mail list logo
