Re : vm: weird behaviour when munmapping
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 VMA is the new one ? >From what you wrote it seems that we call B the new object because it has a new end address... >From my point of view, I called B the old VMA simply because it's going to be destroyed... Francis ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re : vm: weird behaviour when munmapping
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 the last one? */
> last = find_vma(mm, end);
> if (last && end > last->vm_start) {
> int error = split_vma(mm, last, end, 1);
> if (error)
> return error;
> }
>
> So, since its the last VMA that needs to be split (there is only one),
> the new VMA is constructed before the old one. Like so:
>
> A
> A
>
> Then you proceed closing, in this case the new one: B.
Sorry but I don't understand why B is said to be the new one. OK
I can see why from the bit of code you pointed out but from a
logical point of view (ok maybe be me only) I'm unmapping ''
segment, so '' is going to be destroyed and therefore A is
the new one. Thereferore I would expect close(B), open(A)...
no ?
Francis
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re : vm: weird behaviour when munmapping
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, 1024)" I would say that the the new vma is the _upper_ one. lower vma: 0x2aaae000 -> 0x2aaaf000 upper vma: 0x2aaaf000 -> 0x2aab2000 Francis ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vm: weird behaviour when munmapping
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: static void foo_vma_open(struct vm_area_struct *vma) static void foo_vma_close(struct vm_area_struct *vma) A dumb application mmap the device in order to make foo_mmap() install the vma ops. mmap(NULL, 16384, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); mmap returned 0x2aaae000 for example. Until now, foo_vma_open() and foo_vma_close() are not called. Now I want to unmap the first part of the previous mapping to see how vma ops are called. So I did: munmap(0x2aaae000, 1024); and here's what happen: foo_vma_open(vma) is called with: vma->vm_start = 0x2aaae000 vma->vm_end = 0x2aaaf000 foo_vma_close(vma) is called with: vma->vm_start = 0x2aaae000 vma->vm_end = 0x2aaaf000 However I would have expected: foo_vma_open(vma) is called with: vma->vm_start = 0x2aaaf000 vma->vm_end = 0x2aaab2000 foo_vma_close(vma) is called with: vma->vm_start = 0x2aaae000 vma->vm_end = 0x2aaaf000 Can anybody tell me why I get this behaviour ? thanks Francis ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on memory barrier
--- 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, > # rather than use inline assembly to force the particular access (which > # would work equally well), we can force the pointer to a volatile type. > > That's *exactly* what the writel you quote above does! OK but he speaks about special type of access, no ordering constraint. I don't think that MIPS cpu reorder memory access, but gcc can ! And I don't think that the use of 'volatile' can prevent it to do that. > To return to the point directly at hand - on MIPS architectures to date, > simply doing your memory access through a "volatile u32 *" is sufficient > to ensure that the IO hits the bus (assuming that your pointer points to > kseg1, not kseg0, or is otherwise uncached), because 'volatile' forces > gcc to generate a "sw" for each store, and all MIPS so far have been > designed so that multiple uncached writes to mmio locations do generate > multiple bus transactions. ok thanks for this, but once again, there's no ordering constraint garantuee. > > I'm not an architect, but I think it would be possible to build a MIPS > where this was not the case, and require additional contortions from > users. Such a MIPS would suck to program and would probably fail in the > marketplace, and there's no compelling benefit to doing so; ergo, I > would expect "volatile" to continue to be sufficient on MIPS. > I hope so...It's hard to find out an answer to such questions (maybe it's the case only for MIPS arch) although it's an important point. Thanks. Francis ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on memory barrier
--- 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("eieio")" or whatever method your platform requires.)
I'm compiling Linux kernel for a MIPS32 cpu. On my platform, writel seems
expand to:
static inline writel(u32 val, volatile void __iomem *mem)
{
volatile u32 *__mem;
u32 __val;
__mem = (void *)((unsigned long)(mem));
__val = val;
*__mem = __val;
}
I don't see the magic in it since "volatile" keyword do not handle memory
ordering constraints...Linus wrote on volatile keyword, see
http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/1387.html
>
> The sequence points, by themselves, do not make any requirements on the
> externally visible behavior of the program. Nor does the fact that
> there's an inline function involved. It's just the writel() that
> contains the magic to force in-order execution.
>
> You might benefit by running your source code through gcc -E and seeing
> what the writel() expands to. (I do something like "rm drivers/mydev.o;
> make V=1" and then copy-n-paste the gcc line, replacing the "-c -o mydev.o"
> options with -E.)
make drivers/mydev.i should do the job but preprocessor doesn't expand inline
functions. So I won't be able to see the expanded writel function.
>
> The sequence point argument is obviously wrong, BTW - if it were the
> case that a mere sequence point required the compiler to have completed
> all externally-visible side effects, then almost every optimization that
> gcc does with -O2 would be impossible. CSE, loop splitting, etc.
>
> -andy
>
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: question on memory barrier
--- "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 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 inline void dev_out(u32 *reg, u32 value)
> > {
> >writel(value, regs);
> > }
> >
> > void config_dev(void)
> > {
> >dev_out(reg_a, 0x0); /* first io */
> >dev_out(reg_a, 0xA); /* second io */
> > }
> >
>
> This should be fine. The effect of the first bit of code
> plus all side-effects (if any) should be complete at the
> first effective sequence-point (;) but you need to
sorry but I'm not sure to understand you...Do you mean that the first write
into reg_a pointer will be completed before the second write because they're
separated by a (;) ?
Or because writes are encapsulated inside an inline function, therefore
compiler
must execute every single writes before returning from the inline function ?
Thanks.
Francis
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
question on memory barrier
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 inline void dev_out(u32 *reg, u32 value)
{
writel(value, regs);
}
void config_dev(void)
{
dev_out(reg_a, 0x0); /* first io */
dev_out(reg_a, 0xA); /* second io */
}
void config_dev_fixed(void)
{
dev_out(reg_a, 0x0); /* first io */
wmb();
dev_out(reg_a, 0xA); /* second io */
wmb();
}
"""
In this case, am I sure that the order will be respected ? can gcc remove
the first io while optimizing...If so, does "config_dev_fixed" fix it ?
thanks for your answers,
Francis
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [INPUT] simple question on driver initialisation.
--- 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 is still > missing from the sysfs support in input. It'll get there soon. > cool. > > > "pinpad/input0" doesn't sound right. What port is your pinpad connected > > > to? > > > > Actually I'm working on an embedded system which owns a pinpad controller. > > This controller is accessed by using io mem and it talks to the pinpad > through > > a dedicated bus. So I accessed it through io space. > > In that case, you'll likely want something like io0200/input0, where > 0x200 would be the io address of the device. On the other hand, if it's > really embedded and there can't be two pinpads in the system, it's not a > problem to use basically any string there, since it only needs to be > system-unique. > It will be the case: only one embedded pinpad in the system. So something like "kbdport/input0" should be ok... thanks Vojtech for your time. Francis ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [INPUT] simple question on driver initialisation.
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, but > udev can use it to assign a name of the device node. > hmm, how can I use ioctl to find the location device since I need the location to pass it to ioctl ? 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 ? > "pinpad/input0" doesn't sound right. What port is your pinpad connected > to? > Actually I'm working on an embedded system which owns a pinpad controller. This controller is accessed by using io mem and it talks to the pinpad through a dedicated bus. So I accessed it through io space. thanks, Francis. ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [INPUT] simple question on driver initialisation.
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 it, is in /proc/bus/input/devices. I don't see how it can be used for identifiying the device... thanks for your time Francis ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[INPUT] simple question on driver initialisation.
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". What is this field for ? Thanks for your answers, Francis. ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch of a new driver for kernel 2.4.x that need review
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 unreadable. I personnaly don't want to count the position of REG7 in
>> the enum to discover that it's at BASE+7.
>
>
> Sorry, what do you have to count with the following?
> enum {
> TLCLK_REG0 = TLCLK_BASE,
> TLCLK_REG1 = TLCLK_BASE+1,
> TLCLK_REG2 = TLCLK_BASE+2,
> };
> Please note that enums are a general way of specifying _constants_ with the
type int, not necessarily named enumerations.
BTW, a lot of drivers use define for register mapping in kernel. Since enum
is not a new C feature, I'm wondering why kernel have prefered using define
in the past...
thanks,
Francis
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [UART] 8250:RTS/CTS flow control issue.
--- 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 product to work. (Well, you > can, but _you_ would > have to support them.) > well, I don't specially wan't to be immediate. My hardware has "auto flow control" and a 8 bytes fifo...So *whatever* the trigger level is for RTS (actually I can't tune it), I will overrun because the end *driver*, which should be aware of the lack of its "hw auto flow control", decides to fill up its tx fifo to 8 bytes when transmiting... One other solution may be to give the possibility of the user to tune the size of tx fifo ? thanks Francis Découvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Baléares et la Rép. Dominicaine sur Yahoo! Voyages : http://fr.travel.yahoo.com/promotions/mar14.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UART] 8250:RTS/CTS flow control issue.
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. This means that if I deassert RTS when my fifo is 5 bytes full, I can potentially receive 8 bytes and thus get an overrun... But why should I "degrade" my UART because some 8250 devices have poor hardware implementation. Maybe we should limit their tx fifo to one byte when rts/cts flow control is enabled... thanks Francis Découvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Baléares et la Rép. Dominicaine sur Yahoo! Voyages : http://fr.travel.yahoo.com/promotions/mar14.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[UART] 8250:RTS/CTS flow control issue.
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 8250 UARTs have rts/cts line but they're managed by software (and then called hw flow control !!!). Hence when my board's UART (which have a "true" hw flow control) asserts its RTS line, 8250's UART sends 8 bytes before stopping TX... Therefore board's UART fifo have been overrun because it has only 8 bytes for its fifo. Does it mean that we can't do any reliable flow controls with 8250 UART ? In that case a simple workaround would be to limit tx fifo to 1 byte... Thanks Francis Découvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Baléares et la Rép. Dominicaine sur Yahoo! Voyages : http://fr.travel.yahoo.com/promotions/mar14.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TTY] overrun notify issue during 5 minutes after booting
--- 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 call "printk" ? because the former can be called from IT context... Francis Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TTY] overrun notify issue during 5 minutes after booting
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_time" to "jiffies". But it won't work if an overrun appear after a very long while Thanks Francis Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
