Re: [fuse-devel] Re: FUSE merging?

- number of language bindings: 7 (native: C, java, python, perl, - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. 9 now (there is an ocaml binding, and if you dont know ocaml, shame on you). I would just like to ad

[PATCH] dev->priv to netdev_priv(dev), drivers/net/tokenring/

sformation on the whole kernel and it affects around 70 files, most of them in drivers/net/. Should I split my patch for each subnet directories ? (wireless/, wan/, etc) Thanks to Thomas Surrel for helping me refining my semantic patch. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]>

Re: [PATCH] dev->priv to netdev_priv(dev), drivers/net/tokenring/

Jan Engelhardt <[EMAIL PROTECTED]> writes: > On Jul 23 2007 15:18, Yoann Padioleau wrote: >> >>Here is an excerpt of the semantic patch that performs the transformation >> >>@@ >> >>- (T*) dev->priv >>+ netdev_priv(dev) > > Note that dev

[PATCH] 0 -> NULL, drivers/usb/gadget/

same transformation on the whole kernel and it affects around 300 files. I will send the remaining patches if you are interested in. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> config.c |2 +- ether.c |2 +- goku_udc.c|2 +- inode.c |2 +- lh

miss list_del(), bug ?

Shouldn't this code also do a list_del(e) ? in drivers/infiniband/core/iwcm.c: static void dealloc_work_entries(struct iwcm_id_private *cm_id_priv) { struct list_head *e, *tmp; list_for_each_safe(e, tmp, &cm_id_priv->work_free_list) kfree(list_entry(e, struct iw

[PATCH 02/13] dev->priv to netdev_priv(dev), for drivers/net/appletalk

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 03/13] dev->priv to netdev_priv(dev), for drivers/net/arcnet

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 04/13] dev->priv to netdev_priv(dev), for drivers/net/bonding

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 05/13] dev->priv to netdev_priv(dev), for drivers/net/cris

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 06/13] dev->priv to netdev_priv(dev), for drivers/net/ibm_emac

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 07/13] dev->priv to netdev_priv(dev), for drivers/net/irda

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 09/13] dev->priv to netdev_priv(dev), for drivers/net/tokenring

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 10/13] dev->priv to netdev_priv(dev), for drivers/net/tulip

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 11/13] dev->priv to netdev_priv(dev), for drivers/net/usb

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 08/13] dev->priv to netdev_priv(dev), for drivers/net/netxen

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 12/13] dev->priv to netdev_priv(dev), for drivers/net/wan

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

[PATCH 13/13] dev->priv to netdev_priv(dev), for drivers/net/wireless

dev | alloc_etherdev | alloc_trdev ) (sizeof(T), ...) @ rule1bis @ struct net_device *dev; expression E; @@ dev->priv = E @ rule2 depends on rule1 && !rule1bis @ struct net_device *dev; type rule1.T; @@ - (T*) dev->priv + netdev_priv(dev) Signed-off-by: Yoann Padioleau

dev->priv to netdev_priv(dev)

Jeff Garzik <[EMAIL PROTECTED]> writes: >> PS: I have performed the same transformation on the whole kernel >> and it affects around 70 files, most of them in drivers/net/. >> Should I split my patch for each subnet directories ? (wireless/, wan/, etc) > > applied. splitting up by sub-directory w

Re: [PATCH 06/13] dev->priv to netdev_priv(dev), for drivers/net/ibm_emac

Eugene Surovegin <[EMAIL PROTECTED]> writes: > On Fri, Aug 03, 2007 at 07:34:19PM +0200, Yoann Padioleau wrote: >> >> Replacing accesses to dev->priv to netdev_priv(dev). The replacment >> is safe when netdev_priv is used to access a private structure that is &

Re: [PATCH 06/68] 0 -> NULL, for arch/frv

Al Viro <[EMAIL PROTECTED]> writes: > On Fri, Jul 27, 2007 at 11:44:35AM +0200, Yoann Padioleau wrote: >> pte = pte_alloc_kernel(pme, va); >> -if (pte != 0) { >> +if (pte != NULL) { >> err = 0; >> set_pt

[PATCH 16/68] 0 -> NULL, for arch/sparc

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 14/68] 0 -> NULL, for arch/sh

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 12/68] 0 -> NULL, for arch/powerpc

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 08/68] 0 -> NULL, for arch/m68k

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 07/68] 0 -> NULL, for arch/ia64

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 03/68] 0 -> NULL, for arch/arm26

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 01/68] 0 -> NULL, for arch/alpha

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 02/68] 0 -> NULL, for arch/arm

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 04/68] 0 -> NULL, for arch/blackfin

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 05/68] 0 -> NULL, for arch/cris

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 06/68] 0 -> NULL, for arch/frv

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 09/68] 0 -> NULL, for arch/m68knommu

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 10/68] 0 -> NULL, for arch/mips

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 11/68] 0 -> NULL, for arch/parisc

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 13/68] 0 -> NULL, for arch/ppc

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 15/68] 0 -> NULL, for arch/sh64

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 17/68] 0 -> NULL, for arch/sparc64

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 19/68] 0 -> NULL, for arch/x86_64

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

[PATCH 20/68] 0 -> NULL, for arch/xtensa

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAI

[PATCH 18/68] 0 -> NULL, for arch/um

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: [EMAIL PR

Re: [PATCH 06/68] 0 -> NULL, for arch/frv

David Howells <[EMAIL PROTECTED]> writes: > Yoann Padioleau <[EMAIL PROTECTED]> wrote: > >> When comparing a pointer, it's clearer to compare it to NULL than to 0. > > Can you make them of style: > > if (!x) Yes I can. I can make another semantic p

Re: [PATCH 18/68] 0 -> NULL, for arch/um

Jeff Dike <[EMAIL PROTECTED]> writes: > On Fri, Jul 27, 2007 at 11:45:56AM +0200, Yoann Padioleau wrote: >> When comparing a pointer, it's clearer to compare it to NULL than to 0. > > ACK > >> sys-i386/fault.c |2 +- >> sys-x86_64/fault.c |2 +

Re: [PATCH] some kmalloc/memset ->kzalloc (tree wide)

On 7 juil. 07, at 15:07, Tilman Schmidt wrote: Am 06.07.2007 18:51 schrieb Yoann Padioleau: @@ expression E1,E2,E3; @@ - kzalloc(E1 * E2,E3) + kcalloc(E1,E2,E3) This misses the semantic distinction between the first and second arguments of kcalloc(). The first argument is supposed to be

[PATCH] potential parse error

parse error in ifdef or bad use of macro. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> drivers/media/dvb/ttpci/av7110.c |2 +- sound/aoa/codecs/snd-aoa-codec-onyx.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/ttpci/av71

[PATCH] potential parse error, drivers/i2c/busses/i2c-pmcmsp.c

potential parse error in initializer. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> diff --git a/drivers/i2c/busses/i2c-pmcmsp.c b/drivers/i2c/busses/i2c-pmcmsp.c index 03188d2..17cecf1 100644 --- a/drivers/i2c/busses/i2c-pmcmsp.c +++ b/drivers/i2c/busses/i2c-pmcmsp.c @@ -630,7

[PATCH] potential parse error, drivers/serial/dz.h

potential parse error in declaration under a #ifdef. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> diff --git a/drivers/serial/dz.h b/drivers/serial/dz.h index 9674d4e..9141c37 100644 --- a/drivers/serial/dz.h +++ b/drivers/serial/dz.h @@ -125,8 +125,8 @@ #define DZ_XMIT_SIZE

[PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region

In a few files a function such as usb_submit_urb is taking GFP_KERNEL as an argument whereas this function call is inside a spin_lock_irqsave region of code. Documentation says that it must be GFP_ATOMIC instead. Me and my colleagues have made a tool targeting program transformations in device dr

[PATCH] potential parse error in ifdef part 3

parse errors in ifdefs Fix various bits of obviously-busted code which we're not happening to compile, due to ifdefs. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> arch/i386/math-emu/fpu_entry.c |2 +- arch/m68k/mac/debug.c |2 +- arch/ppc/syslib/qspan_pci.

[PATCH] old declaration ritchie style fix in arch/parisc/math-emu/

Use consistent function ANSI declaration style. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> dfadd.c | 10 +- fmpyfadd.c| 30 ++ fpudispatch.c | 22 ++ 3 files changed, 29 insertions(+), 33 deletions(-)

Re: [KJ] Re: [PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region

Andrew Morton <[EMAIL PROTECTED]> writes: >> >> net/wan/lmc/lmc_main.c|2 +- >> scsi/megaraid/megaraid_mm.c |2 +- >> usb/serial/io_ti.c|2 +- >> usb/serial/ti_usb_3410_5052.c |2 +- >> usb/serial/whiteheat.c|6 +++--- >> 5 files changed, 7 inser

Re: [KJ] Re: [PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region

Oliver Neukum <[EMAIL PROTECTED]> writes: > Am Dienstag, 5. Juni 2007 13:05 schrieb Yoann Padioleau: >> Ok. Do you have a preference on the format ?  a : format  ? >> >> Is there a place that gathered all those implicit programming rules >> (that copy_from

[PATCH] potential compiler error, irqfunc caller sites update

found the occurences and fixed the problem. @ rule1 @ identifier fn; identifier irq, dev_id; typedef irqreturn_t; @@ static irqreturn_t fn(int irq, void *dev_id) { ... } @@ identifier rule1.fn; expression E1, E2, E3; @@ fn(E1, E2 - ,E3 ) Signed-off-by: Yoann Padioleau <[EMAIL PROTECT

[PATCH] old declaration ritchie style fix

Use consistent function declaration style. Note that this file is not compiled by make allyesconfig and its configuration option appears nowhere. Perhaps it would be better to remove the file. --- atari_pamsnet.c | 62 +++- 1 file changed,

[PATCH] potential parse error in ifdef

parse error not originally detected by gcc. Here is my (first) patch. Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> Acked-by: Matthew Wilcox <[EMAIL PROTECTED]> --- drivers/char/watchdog/ixp2000_wdt.c |2 +- drivers/mtd/devices/pmc551.c|2 +- drivers/mtd/nan