All of lore.kernel.org
 help / color / mirror / Atom feed
* omap mmc build errors
From: Komal Shah @ 2006-04-10 21:26 UTC (permalink / raw)
  To: linux-omap-open-source

Well, latest OMAP MMC driver even doesn't build for H4. 

drivers/mmc/omap.c: In function `mmc_omap_xfer_data':
drivers/mmc/omap.c:343: warning: unused variable `reg'
drivers/mmc/omap.c:344: warning: unused variable `p'
drivers/mmc/omap.c:1227:30: unterminated argument list invoking macro
"dev_err"
drivers/mmc/omap.c: In function `mmc_omap_dma_cb':
drivers/mmc/omap.c:661: error: `dev_err' undeclared (first use in this
function)
drivers/mmc/omap.c:661: error: (Each undeclared identifier is reported
only once
drivers/mmc/omap.c:661: error: for each function it appears in.)
drivers/mmc/omap.c:661: error: syntax error at end of input
drivers/mmc/omap.c:658: warning: unused variable `mmcdat'
drivers/mmc/omap.c:111: warning: 'dev_attr_cover_switch' defined but
not used
drivers/mmc/omap.c:140: warning: 'dev_attr_enable_poll' defined but not
used
drivers/mmc/omap.c:265: warning: 'mmc_omap_dma_timer' defined but not
used
drivers/mmc/omap.c:275: warning: 'mmc_omap_dma_done' defined but not
used
drivers/mmc/omap.c:383: warning: 'mmc_omap_irq' defined but not used
drivers/mmc/omap.c:520: warning: 'mmc_omap_switch_irq' defined but not
used
drivers/mmc/omap.c:529: warning: 'mmc_omap_switch_timer' defined but
not used
drivers/mmc/omap.c:538: warning: 'mmc_omap_switch_callback' defined but
not used
drivers/mmc/omap.c:542: warning: 'mmc_omap_switch_handler' defined but
not used
drivers/mmc/omap.c:576: warning: 'mmc_omap_prepare_dma' defined but not
used
drivers/mmc/omap.c:656: warning: 'mmc_omap_dma_cb' defined but not used
make[2]: *** [drivers/mmc/omap.o] Error 1
make[1]: *** [drivers/mmc] Error 2
make: *** [drivers] Error 2

Even platform_get_irq is incorrect no. of arguments :). 

---Komal Shah
http://komalshah.blogspot.com/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply

* Re: [Qemu-devel] USB Tablet Emulation
From: Brad Campbell @ 2006-04-10 21:27 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <443AB591.3030501@wasp.net.au>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

Brad Campbell wrote:
> Brad Campbell wrote:
>> Brad Campbell wrote:
>>
>>> The wheel works in SDL although there is currently a bug where it 
>>> steps by 2 instead of 1.. so it's ok for scrolling, but scrolling 
>>> through a selection box causes it to skip every second selection.
>>> I've not tested the wheel with the vnc patch yet. I'll get to those 
>>> tonight..
>>
>> Wheel works in VNC unmodified :) (yay)
>>
>> I've been playing some more on the Win98 calibration issue and I'll 
>> keep looking at that, but for now it' still a no-go. And the 2 step 
>> wheel thing still needs fixing.
> 
> Fixed the descriptor.. Now works perfectly in Win98, 2k and XP :)
> 

Spoke too soon.. revised patch that actually has been completely tested in all 3.
For those thinking of going into a career of hid descriptor writing.. DON'T!

Win98 does not parse the descriptor properly.. and win2k/xp appear to adhere strictly to the specs.
We should now be in a pretty compliant position with all bases covered.

Also attached a small patch to sdl.c which solves the double wheel messages.
The wheel is just 2 buttons.. up and down effectively, and we were sending a delta on both press and 
release of each button, where it should only be a press. This makes the double events go away and I 
can scroll line by line through any listbox or list.

For those that just want to play.
This is a rollup of Anthony's patch, Leo's win2k-hack patch and all my latest fixes plus the vnc 
patch. It applies directly over the latest cvs checkout and is enabled with
-usb -usbdevice tablet.

http://fnarfbargle.dyndns.org:81/qemu/qemu-hid-rfb-ide.patch.gz


Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

[-- Attachment #2: qemu-usb-hid-002.patch --]
[-- Type: text/plain, Size: 2443 bytes --]

--- qemu-clean/hw/usb-hid.c	2006-04-10 23:39:14.000000000 +0400
+++ qemu/hw/usb-hid.c	2006-04-11 01:15:49.000000000 +0400
@@ -161,7 +161,7 @@
         0x00,        /*  u8 country_code */
         0x01,        /*  u8 num_descriptors */
         0x22,        /*  u8 type; Report */
-        65, 0,       /*  u16 len */
+        74, 0,       /*  u16 len */
 
 	/* one endpoint (status change endpoint) */
 	0x07,       /*  u8  ep_bLength; */
@@ -188,29 +188,40 @@
         0xA1, 0x01, /* Collection Application */
         0x09, 0x01, /* Usage Pointer */
         0xA1, 0x00, /* Collection Physical */
-        0x05, 0x09, /* Usage Page Button */
+
+	0x05, 0x09, /* Usage Page Button */
         0x19, 0x01, /* Usage Minimum Button 1 */
         0x29, 0x03, /* Usage Maximum Button 3 */
         0x15, 0x00, /* Logical Minimum 0 */
         0x25, 0x01, /* Logical Maximum 1 */
-        0x95, 0x03, /* Report Count 3 */
+
+	0x95, 0x03, /* Report Count 3 */
         0x75, 0x01, /* Report Size 1 */
         0x81, 0x02, /* Input (Data, Var, Abs) */
         0x95, 0x01, /* Report Count 1 */
         0x75, 0x05, /* Report Size 5 */
-        0x81, 0x01, /* Input (Cnst, Var, Abs) */
+
+	0x81, 0x01, /* Input (Cnst, Var, Abs) */
         0x05, 0x01, /* Usage Page Generic Desktop */
-        0x09, 0x30, /* Usage X */
+	0x09, 0x30, /* Usage X */
         0x09, 0x31, /* Usage Y */
         0x15, 0x00, /* Logical Minimum 0 */
-        0x27, 0xFF, 0xFF, 0x00, 0x00, /* Logical Maximum 0xffff */
-        0x75, 0x10, /* Report Size 16 */
-        0x95, 0x02, /* Report Count 2 */
-        0x81, 0x02, /* Input (Data, Var, Abs) */
+
+	0x26, 0xFF, 0x7F, /* Logical Maximum 0x7fff */
+        0x35, 0x00, /* Physical Minimum 0 */
+        0x46, 0xFE, 0x7F, /* Physical Maximum 0x7fff */
+	0x75, 0x10, /* Report Size 16 */
+
+	0x95, 0x02, /* Report Count 2 */
+	0x81, 0x02, /* Input (Data, Var, Abs) */
+        0x05, 0x01, /* Usage Page Generic Desktop */
         0x09, 0x38, /* Usage Wheel */
         0x15, 0x81, /* Logical Minimum -127 */
-        0x25, 0x7F, /* Logical Maximum 127 */
-        0x75, 0x08, /* Report Size 8 */
+
+	0x25, 0x7F, /* Logical Maximum 127 */
+	0x35, 0x00, /* Physical Minimum 0 (same as logical) */
+	0x45, 0x00, /* Physical Maximum 0 (same as logical) */
+	0x75, 0x08, /* Report Size 8 */
         0x95, 0x01, /* Report Count 1 */
         0x81, 0x02, /* Input (Data, Var, Rel) */
         0xC0,       /* End Collection */

[-- Attachment #3: qemu-sdl-wheel.patch --]
[-- Type: text/plain, Size: 662 bytes --]

--- qemu-clean/sdl.c	2006-04-10 23:43:08.000000000 +0400
+++ qemu/sdl.c	2006-04-11 00:56:01.000000000 +0400
@@ -479,9 +479,9 @@
                     int dz;
                     dz = 0;
 #ifdef SDL_BUTTON_WHEELUP
-                    if (bev->button == SDL_BUTTON_WHEELUP) {
+                    if (bev->button == SDL_BUTTON_WHEELUP && ev->type == SDL_MOUSEBUTTONDOWN) {
                         dz = -1;
-                    } else if (bev->button == SDL_BUTTON_WHEELDOWN) {
+                    } else if (bev->button == SDL_BUTTON_WHEELDOWN && ev->type == SDL_MOUSEBUTTONDOWN) {
                         dz = 1;
                     }
 #endif               

^ permalink raw reply

* Re: Device Mapper as a cache for SAN?
From: Ming Zhang @ 2006-04-10 21:25 UTC (permalink / raw)
  To: device-mapper development
In-Reply-To: <a4e6962a0604101246y5f912a01y72519a6c58291f5@mail.gmail.com>

On Mon, 2006-04-10 at 14:46 -0500, Eric Van Hensbergen wrote:
> On 4/10/06, Ed Wilts <ewilts@ewilts.org> wrote:
> >
> > The obvious question is why?  What would this provide that the kernel
> > and file systems don't already provide?
> >
> 
> Well, kernel provides in-memory page cache, not local disk page cache.
>  There is some ongoing remote file system local disk cache work being
> done, but it applies primarily to AFS and NFS - not block-based
> transports such as iSCSI and AOE.  The various cluster file systems
> may provide something more akin to this, but again, this doesn't
> really cover SAN technologies -- not in any sort of a generic way. 
> Let me know if I'm missing something.

still, what is the main benefit of this cache? what u mean "local disk
page cache"? use "local disk" as page cache or page cache for "local
disk" or something else?

ming


> 
>         -eric
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

^ permalink raw reply

* Cheap Clustered FS
From: Jon Miller @ 2006-04-10 21:24 UTC (permalink / raw)
  To: linux-raid

I have two machines which have redundant paths to the same shared scsi
disk. I've had no problem creating the multipath'ed device md0 to
handle my redundant pathing. But now I'd like to use a simple FS, such
as ext3, mounted rw on the first machine and ro on the second machine.
The idea is that the second machine, mounting the FS ro, would be able
to read any new data being written in the FS.
Everything has been rather easy to setup, but anything being created
on the FS is not seen on the other machine with the FS mounted ro.
That is, I can create a file on the first machine and I never see that
file from the second machine until I remount the FS.
At this point, I am actually trying to avoid GFS, OCFS, veritas
clustered FS options as well as NFS. If there was a simple hack, that
I'm missing, to enable the updates to the FS to be seen in realtime,
then I'd actually prefer that method.
Any help would be appreciated.
--
Thanks,
Jon Miller

^ permalink raw reply

* Re: Signed-off-by again
From: Hollis Blanchard @ 2006-04-10 21:24 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Ross Maxfield, mdday, xen-devel, Ewan Mellor
In-Reply-To: <443AC608.1000505@us.ibm.com>

On Mon, 2006-04-10 at 15:54 -0500, Anthony Liguori wrote:
> Ewan Mellor wrote:
> > On Mon, Apr 10, 2006 at 01:29:13PM -0500, Anthony Liguori wrote:
> >  
> >   
> >> Doesn't this need a Signed-off-by: Ross Maxfield <rmaxfiel@novell.com>?
> >>     
> >
> > People have been complaining that a patch should not retain the Signed-off-by
> > line if the patch has been modified, because they do not sign-off the modified
> > patch.  If a patch needs minor changes before it can be committed, we can
> > either bounce it back to the author, which seems unnecessarily heavyweight, or
> > do what Keir's done here, and sign-off the patch himself.  The From: line
> > retains the audit trail, credit, and copyright, and it's clear that Keir
> > himself thinks that this patch is acceptable.
> >   
> 
> I won't speak for Hollis (although I will CC him :-)) but my 
> understanding is that the appropriate thing to do is check in the patch 
> with the original Signed-off-by and then check in another patch on top 
> of that with the necessary changes (this time, with just Keir's 
> Signed-off-by).
> 
> I think the intention is that the original submitter needs to have a 
> Signed-off-by to signify that the origin of the code is kosher (which is 
> something Keir cannot do on his own if the code didn't originate from 
> him).  Is this how other people understand it?

Actually, now I'm confused about the DCO
(http://www.osdl.org/newsroom/press_releases/2004/2004_05_24_dco.html).
The terms seem to allow adding Signed-off-by lines when making
modifications, but that seems obviously in conflict point of the system.

See also Linus's mail at http://kerneltrap.org/node/3180:
        It also allows middle parties to edit the patch without somehow
        "losing" their names - quite often the patch that reaches the
        final kernel is not exactly the same as the original one, as it
        has gone through a few layers of people.

So in the Linux system, it is OK for Keir to modify (not rewrite) and
add his Signed-off-by after all.

The reason I don't like that is this example:
- Mary submits a clean patch with signed-off-by line
- Joe adds some bad IP to Mary's patch (e.g. some proprietary
copyrighted code), adds his signed-off-by line, and forwards on
- patch is checked in
- lawyers find the infringing patch, and look, there's Mary apparently
signing off on it

We could follow the Linux system, or something stronger (i.e. no
modifications to other people's patches allowed). I guess it's up to the
maintainers...

Whatever is chosen, it needs to be *documented* (beyond just the DCO URL
above) and adhered to.

-- 
Hollis Blanchard
IBM Linux Technology Center

^ permalink raw reply

* SVN_URL undocumented
From: Pavel Roskin @ 2006-04-10 21:22 UTC (permalink / raw)
  To: Eric Wong; +Cc: git

Hello, Eric!

I'm trying to use git-svn, but the documentation seems to be quite
unclear.  I'm using current git-svn from the git repository.

I'm running "git-svn init" in a Subversion working directory:

$ git-svn init
SVN repository location required
 at /home/proski/bin/git-svn line 223
        main::init() called at /home/proski/bin/git-svn line 104

The help shown by git-svn without arguments doesn't say anything about
arguments for "init", unlike other subcommands.  I'm assuming that
"git-svn init" is not taking any arguments.

The manual page doesn't say anything about arguments, but it mentions
that "the SVN_URL must be specified at this point".  This statement is
unclear to me.

There are several references to SVN_URL in the manual, but there is no
description what it is.  Is it supposed to be an environment variable,
or an undocumented argument, or is it taken from "svn info" output?

The environment variable has no effect:

$ SVN_URL=http://svn.madwifi.org/trunk git-svn init
SVN repository location required
 at /home/proski/bin/git-svn line 223
        main::init() called at /home/proski/bin/git-svn line 104

Looking at the sources, it looks like that SVN_URL is an undocumented
argument for "git-cvs init".  "git-svn fetch" appears to be taking that
value from the git repository, but it also takes care to protect the
original value (I have no idea where it can come from).

One of the "basic examples" further in the manual confirms that SVN_URL
is set on the command line:

git-svn init http://svn.foo.org/project/trunk

I believe that the documentation should be updated to describe where
SVN_URL comes from, and what arguments are accepted by "git-svn init".
Basic examples shouldn't recommend using undocumented arguments.

It seems to me that the current documentation describes the internals of
git-svn instead of its user interface.  Rather than tell the user that
"FOO must be specified at that point", the documentation should say what
(an how) should (or can) be specified when the command is invoked on the
command line.

Also, it would be great to refer to the "additional fetch arguments" in
the "fetch" description.  That section is easy to miss by somebody who
is specifically looking for "fetch arguments".

-- 
Regards,
Pavel Roskin

^ permalink raw reply

* [PATCH 2/2] vfs: fix up signature of flush operations
From: Miklos Szeredi @ 2006-04-10 21:21 UTC (permalink / raw)
  To: akpm; +Cc: linux-fsdevel, linux-kernel, viro

Add lock owner ID argument to flush operations.  This makes the
warning go away, but otherwise has no effect.

Compile tested (mostly).

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Index: linux/arch/ia64/kernel/perfmon.c
===================================================================
--- linux.orig/arch/ia64/kernel/perfmon.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/arch/ia64/kernel/perfmon.c	2006-04-09 11:19:01.000000000 +0200
@@ -532,7 +532,6 @@ static ctl_table pfm_sysctl_root[] = {
 static struct ctl_table_header *pfm_sysctl_header;
 
 static int pfm_context_unload(pfm_context_t *ctx, void *arg, int count, struct pt_regs *regs);
-static int pfm_flush(struct file *filp);
 
 #define pfm_get_cpu_var(v)		__ia64_per_cpu_var(v)
 #define pfm_get_cpu_data(a,b)		per_cpu(a, b)
@@ -1773,7 +1772,7 @@ pfm_syswide_cleanup_other_cpu(pfm_contex
  * When caller is self-monitoring, the context is unloaded.
  */
 static int
-pfm_flush(struct file *filp)
+pfm_flush(struct file *filp, fl_owner_t id)
 {
 	pfm_context_t *ctx;
 	struct task_struct *task;
Index: linux/drivers/input/evdev.c
===================================================================
--- linux.orig/drivers/input/evdev.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/input/evdev.c	2006-04-09 11:19:01.000000000 +0200
@@ -82,7 +82,7 @@ static int evdev_fasync(int fd, struct f
 	return retval < 0 ? retval : 0;
 }
 
-static int evdev_flush(struct file * file)
+static int evdev_flush(struct file * file, fl_owner_t id)
 {
 	struct evdev_list *list = file->private_data;
 	if (!list->evdev->exist) return -ENODEV;
Index: linux/drivers/scsi/osst.c
===================================================================
--- linux.orig/drivers/scsi/osst.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/scsi/osst.c	2006-04-09 11:19:01.000000000 +0200
@@ -4724,7 +4724,7 @@ err_out:
 
 
 /* Flush the tape buffer before close */
-static int os_scsi_tape_flush(struct file * filp)
+static int os_scsi_tape_flush(struct file * filp, fl_owner_t id)
 {
 	int		      result = 0, result2;
 	struct osst_tape    * STp    = filp->private_data;
Index: linux/drivers/scsi/st.c
===================================================================
--- linux.orig/drivers/scsi/st.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/scsi/st.c	2006-04-09 11:19:01.000000000 +0200
@@ -1193,7 +1193,7 @@ static int st_open(struct inode *inode, 
 \f
 
 /* Flush the tape buffer before close */
-static int st_flush(struct file *filp)
+static int st_flush(struct file *filp, fl_owner_t id)
 {
 	int result = 0, result2;
 	unsigned char cmd[MAX_COMMAND_SIZE];
Index: linux/fs/cifs/cifsfs.h
===================================================================
--- linux.orig/fs/cifs/cifsfs.h	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/cifs/cifsfs.h	2006-04-09 11:19:01.000000000 +0200
@@ -74,7 +74,7 @@ extern ssize_t cifs_user_write(struct fi
 			 size_t write_size, loff_t * poffset);
 extern int cifs_lock(struct file *, int, struct file_lock *);
 extern int cifs_fsync(struct file *, struct dentry *, int);
-extern int cifs_flush(struct file *);
+extern int cifs_flush(struct file *, fl_owner_t id);
 extern int cifs_file_mmap(struct file * , struct vm_area_struct *);
 extern const struct file_operations cifs_dir_ops;
 extern int cifs_dir_open(struct inode *inode, struct file *file);
Index: linux/fs/cifs/file.c
===================================================================
--- linux.orig/fs/cifs/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/cifs/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -1409,7 +1409,7 @@ int cifs_fsync(struct file *file, struct
  * As file closes, flush all cached write data for this inode checking
  * for write behind errors.
  */
-int cifs_flush(struct file *file)
+int cifs_flush(struct file *file, fl_owner_t id)
 {
 	struct inode * inode = file->f_dentry->d_inode;
 	int rc = 0;
Index: linux/fs/coda/file.c
===================================================================
--- linux.orig/fs/coda/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/coda/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -164,7 +164,7 @@ int coda_open(struct inode *coda_inode, 
 	return 0;
 }
 
-int coda_flush(struct file *coda_file)
+int coda_flush(struct file *coda_file, fl_owner_t id)
 {
 	unsigned short flags = coda_file->f_flags & ~O_EXCL;
 	unsigned short coda_flags = coda_flags_to_cflags(flags);
Index: linux/include/linux/coda_linux.h
===================================================================
--- linux.orig/include/linux/coda_linux.h	2006-04-09 11:17:01.000000000 +0200
+++ linux/include/linux/coda_linux.h	2006-04-09 11:19:01.000000000 +0200
@@ -36,7 +36,7 @@ extern const struct file_operations coda
 
 /* operations shared over more than one file */
 int coda_open(struct inode *i, struct file *f);
-int coda_flush(struct file *f);
+int coda_flush(struct file *f, fl_owner_t id);
 int coda_release(struct inode *i, struct file *f);
 int coda_permission(struct inode *inode, int mask, struct nameidata *nd);
 int coda_revalidate_inode(struct dentry *);
Index: linux/fs/fuse/file.c
===================================================================
--- linux.orig/fs/fuse/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/fuse/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -169,7 +169,7 @@ static int fuse_release(struct inode *in
 	return fuse_release_common(inode, file, 0);
 }
 
-static int fuse_flush(struct file *file)
+static int fuse_flush(struct file *file, fl_owner_t id)
 {
 	struct inode *inode = file->f_dentry->d_inode;
 	struct fuse_conn *fc = get_fuse_conn(inode);
Index: linux/fs/nfs/file.c
===================================================================
--- linux.orig/fs/nfs/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/nfs/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -43,7 +43,7 @@ static int  nfs_file_mmap(struct file *,
 static ssize_t nfs_file_sendfile(struct file *, loff_t *, size_t, read_actor_t, void *);
 static ssize_t nfs_file_read(struct kiocb *, char __user *, size_t, loff_t);
 static ssize_t nfs_file_write(struct kiocb *, const char __user *, size_t, loff_t);
-static int  nfs_file_flush(struct file *);
+static int  nfs_file_flush(struct file *, fl_owner_t id);
 static int  nfs_fsync(struct file *, struct dentry *dentry, int datasync);
 static int nfs_check_flags(int flags);
 static int nfs_lock(struct file *filp, int cmd, struct file_lock *fl);
@@ -188,7 +188,7 @@ static loff_t nfs_file_llseek(struct fil
  *
  */
 static int
-nfs_file_flush(struct file *file)
+nfs_file_flush(struct file *file, fl_owner_t id)
 {
 	struct nfs_open_context *ctx = (struct nfs_open_context *)file->private_data;
 	struct inode	*inode = file->f_dentry->d_inode;
Index: linux/ipc/mqueue.c
===================================================================
--- linux.orig/ipc/mqueue.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/ipc/mqueue.c	2006-04-09 11:19:01.000000000 +0200
@@ -356,7 +356,7 @@ static ssize_t mqueue_read_file(struct f
 	return count;
 }
 
-static int mqueue_flush_file(struct file *filp)
+static int mqueue_flush_file(struct file *filp, fl_owner_t id)
 {
 	struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode);
 

^ permalink raw reply

* [PATCH 2/2] vfs: fix up signature of flush operations
From: Miklos Szeredi @ 2006-04-10 21:21 UTC (permalink / raw)
  To: akpm; +Cc: linux-fsdevel, linux-kernel, viro

Add lock owner ID argument to flush operations.  This makes the
warning go away, but otherwise has no effect.

Compile tested (mostly).

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Index: linux/arch/ia64/kernel/perfmon.c
===================================================================
--- linux.orig/arch/ia64/kernel/perfmon.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/arch/ia64/kernel/perfmon.c	2006-04-09 11:19:01.000000000 +0200
@@ -532,7 +532,6 @@ static ctl_table pfm_sysctl_root[] = {
 static struct ctl_table_header *pfm_sysctl_header;
 
 static int pfm_context_unload(pfm_context_t *ctx, void *arg, int count, struct pt_regs *regs);
-static int pfm_flush(struct file *filp);
 
 #define pfm_get_cpu_var(v)		__ia64_per_cpu_var(v)
 #define pfm_get_cpu_data(a,b)		per_cpu(a, b)
@@ -1773,7 +1772,7 @@ pfm_syswide_cleanup_other_cpu(pfm_contex
  * When caller is self-monitoring, the context is unloaded.
  */
 static int
-pfm_flush(struct file *filp)
+pfm_flush(struct file *filp, fl_owner_t id)
 {
 	pfm_context_t *ctx;
 	struct task_struct *task;
Index: linux/drivers/input/evdev.c
===================================================================
--- linux.orig/drivers/input/evdev.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/input/evdev.c	2006-04-09 11:19:01.000000000 +0200
@@ -82,7 +82,7 @@ static int evdev_fasync(int fd, struct f
 	return retval < 0 ? retval : 0;
 }
 
-static int evdev_flush(struct file * file)
+static int evdev_flush(struct file * file, fl_owner_t id)
 {
 	struct evdev_list *list = file->private_data;
 	if (!list->evdev->exist) return -ENODEV;
Index: linux/drivers/scsi/osst.c
===================================================================
--- linux.orig/drivers/scsi/osst.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/scsi/osst.c	2006-04-09 11:19:01.000000000 +0200
@@ -4724,7 +4724,7 @@ err_out:
 
 
 /* Flush the tape buffer before close */
-static int os_scsi_tape_flush(struct file * filp)
+static int os_scsi_tape_flush(struct file * filp, fl_owner_t id)
 {
 	int		      result = 0, result2;
 	struct osst_tape    * STp    = filp->private_data;
Index: linux/drivers/scsi/st.c
===================================================================
--- linux.orig/drivers/scsi/st.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/drivers/scsi/st.c	2006-04-09 11:19:01.000000000 +0200
@@ -1193,7 +1193,7 @@ static int st_open(struct inode *inode, 
 \f


 
 /* Flush the tape buffer before close */
-static int st_flush(struct file *filp)
+static int st_flush(struct file *filp, fl_owner_t id)
 {
 	int result = 0, result2;
 	unsigned char cmd[MAX_COMMAND_SIZE];
Index: linux/fs/cifs/cifsfs.h
===================================================================
--- linux.orig/fs/cifs/cifsfs.h	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/cifs/cifsfs.h	2006-04-09 11:19:01.000000000 +0200
@@ -74,7 +74,7 @@ extern ssize_t cifs_user_write(struct fi
 			 size_t write_size, loff_t * poffset);
 extern int cifs_lock(struct file *, int, struct file_lock *);
 extern int cifs_fsync(struct file *, struct dentry *, int);
-extern int cifs_flush(struct file *);
+extern int cifs_flush(struct file *, fl_owner_t id);
 extern int cifs_file_mmap(struct file * , struct vm_area_struct *);
 extern const struct file_operations cifs_dir_ops;
 extern int cifs_dir_open(struct inode *inode, struct file *file);
Index: linux/fs/cifs/file.c
===================================================================
--- linux.orig/fs/cifs/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/cifs/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -1409,7 +1409,7 @@ int cifs_fsync(struct file *file, struct
  * As file closes, flush all cached write data for this inode checking
  * for write behind errors.
  */
-int cifs_flush(struct file *file)
+int cifs_flush(struct file *file, fl_owner_t id)
 {
 	struct inode * inode = file->f_dentry->d_inode;
 	int rc = 0;
Index: linux/fs/coda/file.c
===================================================================
--- linux.orig/fs/coda/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/coda/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -164,7 +164,7 @@ int coda_open(struct inode *coda_inode, 
 	return 0;
 }
 
-int coda_flush(struct file *coda_file)
+int coda_flush(struct file *coda_file, fl_owner_t id)
 {
 	unsigned short flags = coda_file->f_flags & ~O_EXCL;
 	unsigned short coda_flags = coda_flags_to_cflags(flags);
Index: linux/include/linux/coda_linux.h
===================================================================
--- linux.orig/include/linux/coda_linux.h	2006-04-09 11:17:01.000000000 +0200
+++ linux/include/linux/coda_linux.h	2006-04-09 11:19:01.000000000 +0200
@@ -36,7 +36,7 @@ extern const struct file_operations coda
 
 /* operations shared over more than one file */
 int coda_open(struct inode *i, struct file *f);
-int coda_flush(struct file *f);
+int coda_flush(struct file *f, fl_owner_t id);
 int coda_release(struct inode *i, struct file *f);
 int coda_permission(struct inode *inode, int mask, struct nameidata *nd);
 int coda_revalidate_inode(struct dentry *);
Index: linux/fs/fuse/file.c
===================================================================
--- linux.orig/fs/fuse/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/fuse/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -169,7 +169,7 @@ static int fuse_release(struct inode *in
 	return fuse_release_common(inode, file, 0);
 }
 
-static int fuse_flush(struct file *file)
+static int fuse_flush(struct file *file, fl_owner_t id)
 {
 	struct inode *inode = file->f_dentry->d_inode;
 	struct fuse_conn *fc = get_fuse_conn(inode);
Index: linux/fs/nfs/file.c
===================================================================
--- linux.orig/fs/nfs/file.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/nfs/file.c	2006-04-09 11:19:01.000000000 +0200
@@ -43,7 +43,7 @@ static int  nfs_file_mmap(struct file *,
 static ssize_t nfs_file_sendfile(struct file *, loff_t *, size_t, read_actor_t, void *);
 static ssize_t nfs_file_read(struct kiocb *, char __user *, size_t, loff_t);
 static ssize_t nfs_file_write(struct kiocb *, const char __user *, size_t, loff_t);
-static int  nfs_file_flush(struct file *);
+static int  nfs_file_flush(struct file *, fl_owner_t id);
 static int  nfs_fsync(struct file *, struct dentry *dentry, int datasync);
 static int nfs_check_flags(int flags);
 static int nfs_lock(struct file *filp, int cmd, struct file_lock *fl);
@@ -188,7 +188,7 @@ static loff_t nfs_file_llseek(struct fil
  *
  */
 static int
-nfs_file_flush(struct file *file)
+nfs_file_flush(struct file *file, fl_owner_t id)
 {
 	struct nfs_open_context *ctx = (struct nfs_open_context *)file->private_data;
 	struct inode	*inode = file->f_dentry->d_inode;
Index: linux/ipc/mqueue.c
===================================================================
--- linux.orig/ipc/mqueue.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/ipc/mqueue.c	2006-04-09 11:19:01.000000000 +0200
@@ -356,7 +356,7 @@ static ssize_t mqueue_read_file(struct f
 	return count;
 }
 
-static int mqueue_flush_file(struct file *filp)
+static int mqueue_flush_file(struct file *filp, fl_owner_t id)
 {
 	struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode);
 

^ permalink raw reply

* [PATCH 1/2] vfs: add lock owner argument to flush operation
From: Miklos Szeredi @ 2006-04-10 21:19 UTC (permalink / raw)
  To: akpm; +Cc: linux-fsdevel, linux-kernel, viro

Pass the POSIX lock owner ID to the flush operation.

This is useful for filesystems which don't want to store any locking
state in inode->i_flock but want to handle locking/unlocking POSIX
locks internally.  FUSE is one such filesystem but I think it possible
that some network filesystems would need this also.

Also add a flag to indicate that a POSIX locking request was generated
by close(), so filesystems using the above feature won't send an extra
locking request in this case.

f_op->flush() is only called from filp_close().  Since the added
argument may safely be ignored by filesystems the API/ABI remains
backward compatible.  Only a compile time warning is generated if the
signature of the flush method is old.  The next patch fixes up all the
in-tree uses of flush(), out-of-tree uses can migrate at will.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h	2006-04-09 11:17:01.000000000 +0200
+++ linux/include/linux/fs.h	2006-04-09 11:18:58.000000000 +0200
@@ -679,6 +679,7 @@ extern spinlock_t files_lock;
 #define FL_FLOCK	2
 #define FL_ACCESS	8	/* not trying to lock, just looking */
 #define FL_LEASE	32	/* lease held on this file */
+#define FL_CLOSE	64	/* unlock on close */
 #define FL_SLEEP	128	/* A blocking lock */
 
 /*
@@ -1025,7 +1026,7 @@ struct file_operations {
 	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
 	int (*mmap) (struct file *, struct vm_area_struct *);
 	int (*open) (struct inode *, struct file *);
-	int (*flush) (struct file *);
+	int (*flush) (struct file *, fl_owner_t id);
 	int (*release) (struct inode *, struct file *);
 	int (*fsync) (struct file *, struct dentry *, int datasync);
 	int (*aio_fsync) (struct kiocb *, int datasync);
Index: linux/fs/locks.c
===================================================================
--- linux.orig/fs/locks.c	2006-04-09 11:17:58.000000000 +0200
+++ linux/fs/locks.c	2006-04-09 11:18:58.000000000 +0200
@@ -1902,7 +1902,7 @@ void locks_remove_posix(struct file *fil
 		return;
 
 	lock.fl_type = F_UNLCK;
-	lock.fl_flags = FL_POSIX;
+	lock.fl_flags = FL_POSIX | FL_CLOSE;
 	lock.fl_start = 0;
 	lock.fl_end = OFFSET_MAX;
 	lock.fl_owner = owner;
Index: linux/fs/open.c
===================================================================
--- linux.orig/fs/open.c	2006-04-09 11:17:01.000000000 +0200
+++ linux/fs/open.c	2006-04-09 11:18:58.000000000 +0200
@@ -1137,7 +1137,7 @@ int filp_close(struct file *filp, fl_own
 	}
 
 	if (filp->f_op && filp->f_op->flush)
-		retval = filp->f_op->flush(filp);
+		retval = filp->f_op->flush(filp, id);
 
 	dnotify_flush(filp, id);
 	locks_remove_posix(filp, id);

^ permalink raw reply

* Re: [RFC: 2.6 patch] remove unused ide_init_default_hwifs()'s
From: Russell King @ 2006-04-10 21:18 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: B.Zolnierkiewicz, linux-kernel, linux-ide, starvik, dev-etrax
In-Reply-To: <20060410203950.GG2408@stusta.de>

On Mon, Apr 10, 2006 at 10:39:50PM +0200, Adrian Bunk wrote:
> --- linux-2.6.17-rc1-mm2-full/include/asm-arm/arch-sa1100/ide.h.old	2006-04-10 21:15:04.000000000 +0200
> +++ linux-2.6.17-rc1-mm2-full/include/asm-arm/arch-sa1100/ide.h	2006-04-10 21:15:37.000000000 +0200
> @@ -49,28 +49,3 @@
>  		*irq = 0;
>  }
>  
> -/*
> - * This registers the standard ports for this architecture with the IDE
> - * driver.
> - */
> -static __inline__ void
> -ide_init_default_hwifs(void)
> -{
> -    if (machine_is_lart()) {
> -#ifdef CONFIG_SA1100_LART
> -        hw_regs_t hw;
> -
> -        /* Enable GPIO as interrupt line */
> -        GPDR &= ~LART_GPIO_IDE;
> -	set_irq_type(LART_IRQ_IDE, IRQT_RISING);
> -
> -        /* set PCMCIA interface timing */
> -        MECR = 0x00060006;
> -
> -        /* init the interface */
> -	ide_init_hwif_ports(&hw, PCMCIA_IO_0_BASE + 0x0000, PCMCIA_IO_0_BASE + 0x1000, NULL);
> -        hw.irq = LART_IRQ_IDE;
> -        ide_register_hw(&hw);
> -#endif
> -    }
> -}

NAK.  Waiting for the LART folk to get off their backsides and submit a
patch to do what's required.  Think of the above as merely documentation
for what's required.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply

* Re: HSG80, DM, multipath issues
From: Christophe Varoqui @ 2006-04-10 21:16 UTC (permalink / raw)
  To: device-mapper development
In-Reply-To: <20060410204822.GA6573@tditx.com>

D. North a écrit :
> Thus spake Christophe Varoqui (christophe.varoqui@free.fr):
>
>   
>> The one I used is "force a bounce per LUN just after driver loading", 
>> which this snippet does :
>>
>>        sg_start -s 1 /dev/$i
>>     
>
>
> Thanks! ... This got me going enough to get a /dev/mapper/lun4p1...p3 up & running!
> This was done manually from a 'rescue mode' boot of SuSE 10.
>
> After trying the required commands on a running system, it's clear now that the
> device mapper setup has to be done in the initrd if I expect to boot from this
> array. No problem there... that's just a comment.
>
> What is troubling me more at the moment is the difference between the device
> mapper table setup commands created by the multipath command and how they
> are different from what dm-mpath.c is actually expecting.
>
> I downloaded 0.4.7 multipath tools & verified that they produce the same
> table setup issues that I'm having trouble with from the 0.4.5 tool that
> is current with SuSE 10. For example, the SuSE version of multipath command
> produces this:
>        0 443027195 multipath 0 0 2 1 round-robin 1 1 8:0 1000 round-robin 1 1 8:16 1000
> Which produces the previously mentioned misparse in dm-mpath.c (my debugging mods)
>        Apr 10 15:30:35 orthus-san kernel: nr_params is 1001, nr_selector_args = 1000, pg->nr_pgpaths is 8
>
> Multipath tools 0.4.7 also causes the same diagnostic message (from my
> debugging modifications), and it is sending in the same number of arguments
> (14) to dm-mpath.c.  I don't, however, get the diagnostic message any more from
> this version of multipath to determine what it is actually sending into
> libdevmapper, so I am not, at the moment, absolutely certain that the argument
> list is the same as 0.4.5.
>
> To bypass the misparse, I can still use a command like this:
>        # echo 0 443027195 multipath 0 0 2 1 round-robin 1 1 1 0 8:0 round-robin 1 1 1 0 8:16 | dmsetup create lun4
>
> I have successfully set up a device mapper mapping that I can read & write
> to from a rescue system, so the above command does actually work.
>
> Unfortunately, if I correctly understand what I'm seeing, this means that the
> current multipath tools 0.4.7 is incompatible with the dm_multipath module in
> my 2.6.13-15.8 kernel. Also, this would seem to mean that multipathd is also
> incompatible with this kernel.
>
>   
Taken from "The Source", the multipath target syntax is :

/*-----------------------------------------------------------------
 * Constructor/argument parsing:
 * <#multipath feature args> [<arg>]*
 * <#hw_handler args> [hw_handler [<arg>]*]
 * <#priority groups>
 * <initial priority group>
 *     [<selector> <#selector args> [<arg>]*
 *      <#paths> <#per-path selector args>
 *         [<path> [<arg>]* ]+ ]+
 *---------------------------------------------------------------*/

1000 is the default number of IO routed to a path before the driver 
switches to the next path in the same pathgroup. This is the simple way 
to achieve the load-leveling through the "round-robin" selector.

Maybe confusingly, the rr_min_io is the "per-path selector args".
Thus, for a path group in your setup :

<selector> = round-robin
<#selector args> = 0
[<arg>]* = NULL
<#paths> = 1 (in your case)
<#per-path selector args> = 1 (for rr_min_io)
<path> = 8:0 (for one)
[<arg>]* = 1000 (default rr_min_io, proper)

What strikes me in this map "0 443027195 multipath 0 0 2 1 round-robin 1 
1 8:0 1000 round-robin 1 1 8:16 1000" is the lack of <#selector args>.

... but I don't reproduce here : "0 71122560 multipath 1 
queue_if_no_path 0 2 1 round-robin 0 1 1 8:32 100 round-robin 0 1 1 8:80 
100"

> Is anyone aware of a workaround or even a better identification for this
> incompatibility?
>
> Thanks!
>   

^ permalink raw reply

* Re: Setting up new dosemu 1.3.3
From: Larry Alkoff @ 2006-04-10 21:15 UTC (permalink / raw)
  To: Claudia Neumann; +Cc: dosemu
In-Reply-To: <200604102225.44620.dr.claudia.neumann@gmx.de>

Claudia Neumann wrote:
> Am Montag, 10. April 2006 19:05 schrieben Sie:
>> I used to run dosemu-1.2.2 and was able to get a very nice dosemu window
>> under KDE with a large 12x21 font in an 80x25 window.
>>
>> Most of my dos programs require 80x25 and my tired old eyes really need
>> a large font.
>>
>> How can I get the large font with dosemu-1.3.3?
>>
>> Background:
>>
>> To run dosemu-1.2.2 I had a KDE icon with the command line:
>> kstart /usr/X11R6/bin/xterm -geometry 80x25 -font 12x24 -e godos -x
>>
>> The xterm produced had a nice large font and 80x25 screen
>> with white background and,
>> godos is a script that runs dosemu after a two second delay
>> to give a large font white letter on black screen exactly the same size
>> and location as the xterm (convers it up).
>>
>> When the same setup runs now, it produces the large xterm, but when
>> dosemu runs it creates a separate small white letter on black window.
>> The window is 80x25 but the fonts are too small to comfortably read.
>>
>> How can I increase the larger fonts?
> 
> http://marc.theaimsgroup.com/?l=linux-msdos&m=114374588406598&w=2
> 
> Claudia 
> 

Thank you very very much Claudia.  I copied your web page into my 
dosemu.nfo file.

After experimenting with the fonts installed by dosemu, I simply entered 
the 12x24 font I liked from with 1.2.2 from /usr/X11R6/lib/X11/fonts/misc
(not in /usr/local/share/dosemu/Xfonts) and it worked perfectly!
This makes my life a lot easier.

Finally I'm going to be able to use my old favorite dos programs (WS 
SuperCalc and Q&A) without eyestrain.

Do you have any advice for changing the white letters on black to 
something nicer like black letters on light background?

Larry

-- 
Larry Alkoff N2LA - Austin TX
Using Thunderbird on Slackware Linux

^ permalink raw reply

* Re: [spi-devel-general] [PATCH][2.16.17-rc1-mm2] spi: Added spi master driver for Freescale MPC83xx SPI controller
From: Kumar Gala @ 2006-04-10 21:10 UTC (permalink / raw)
  To: David Brownell; +Cc: Vitaly Wool, Greg KH, linux-kernel, spi-devel-general
In-Reply-To: <200604101406.55269.david-b@pacbell.net>


On Apr 10, 2006, at 4:06 PM, David Brownell wrote:

> On Monday 10 April 2006 1:22 pm, Kumar Gala wrote:
>>
>
>> I wasn't particular happy about the spinning for ever, wasn't sure
>> what would be better.  I need to ensure we've gotten both a TX & RX
>> event before transmitting the next character.  I'm open to
>> suggestions on how to do this better.
>
> I figured that it's impossible to get an RX event without the TX
> having completed.  :)

Should I just get ride of the spin loop then?

- k

^ permalink raw reply

* Re: [spi-devel-general] [PATCH][2.16.17-rc1-mm2] spi: Added spi master driver for Freescale MPC83xx SPI controller
From: David Brownell @ 2006-04-10 21:06 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Vitaly Wool, Greg KH, linux-kernel, spi-devel-general
In-Reply-To: <EB5A4A6A-BCD0-4DD0-A0F4-E155495EDCC6@kernel.crashing.org>

On Monday 10 April 2006 1:22 pm, Kumar Gala wrote:
> 

> I wasn't particular happy about the spinning for ever, wasn't sure  
> what would be better.  I need to ensure we've gotten both a TX & RX  
> event before transmitting the next character.  I'm open to  
> suggestions on how to do this better.

I figured that it's impossible to get an RX event without the TX
having completed.  :)

- Dave


^ permalink raw reply

* Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
From: Marc L. de Bruin @ 2006-04-10 21:05 UTC (permalink / raw)
  To: dean gaudet; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.64.0604101128290.29514@twinlark.arctic.org>

dean gaudet wrote:
> On Mon, 10 Apr 2006, Marc L. de Bruin wrote:
> 
>> However, all "preferred minor"s are correct, meaning that the output is in
>> sync with what I expected it to be from /etc/mdadm/mdadm.conf.
>>
>> Any other ideas? Just adding /etc/mdadm/mdadm.conf to the initrd does not seem
>> to work, since mdrun seems to ignore it?!

> it seems to me "mdrun /dev" is about the worst thing possible to use in an 
> initrd.

:-)

I guess I'll have to change to yaird asap then. I can't think of any other 
solid solution...

Marc.

^ permalink raw reply

* Re: [PATCH 11/19] kconfig: move .kernelrelease
From: Andrew Morton @ 2006-04-10 20:02 UTC (permalink / raw)
  To: Roman Zippel; +Cc: sam, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604101523031.32445@scrub.home>

Roman Zippel <zippel@linux-m68k.org> wrote:
>
> On Mon, 10 Apr 2006, Andrew Morton wrote:
> 
>  > hm, it takes nearly five seconds, but it wasn't that - something actually
>  > broke.  But I forget what it was.  I'll put it back and will wait for it
>  > to reoccur.
> 
>  The patch below should speed this up.

It went from 5 seconds down to 4 seconds.

> You know that you have to update 
>  this file explicitly?

That depends on what "explicitly" means.   `make oldconfig' updates it.

^ permalink raw reply

* Re: Re: [Xen-changelog] If the 'cdrom=' option is specified in the definition file but media is
From: Anthony Liguori @ 2006-04-10 21:02 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: Ross Maxfield, xen-devel, Hollis Blanchard
In-Reply-To: <20060410192930.GA12825@leeni.uk.xensource.com>

Ewan Mellor wrote:
> On Mon, Apr 10, 2006 at 01:29:13PM -0500, Anthony Liguori wrote:
>  
>   
>> Doesn't this need a Signed-off-by: Ross Maxfield <rmaxfiel@novell.com>?
>>     
>
> People have been complaining that a patch should not retain the Signed-off-by
> line if the patch has been modified, because they do not sign-off the modified
> patch.  If a patch needs minor changes before it can be committed, we can
> either bounce it back to the author, which seems unnecessarily heavyweight, or
> do what Keir's done here, and sign-off the patch himself.  The From: line
> retains the audit trail, credit, and copyright, and it's clear that Keir
> himself thinks that this patch is acceptable.
>   

I won't speak for Hollis (although I will CC him :-)) but my 
understanding is that the appropriate thing to do is check in the patch 
with the original Signed-off-by and then check in another patch on top 
of that with the necessary changes (this time, with just Keir's 
Signed-off-by).

I think the intention is that the original submitter needs to have a 
Signed-off-by to signify that the origin of the code is kosher (which is 
something Keir cannot do on his own if the code didn't originate from 
him).  Is this how other people understand it?

Regards,

Anthony Liguori

> Ewan.
>   

^ permalink raw reply

* Re: Re: [Xen-changelog] If the 'cdrom=' option is specified in the definition file but media is
From: Mike D. Day @ 2006-04-10 20:56 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: Ross Maxfield, xen-devel
In-Reply-To: <20060410192930.GA12825@leeni.uk.xensource.com>

Ewan Mellor wrote:
>>> From: Ross Maxfield <rmaxfiel@novell.com>
>>>
>>> Signed-off-by: Keir Fraser <keir@xensource.com>
>>>  
>> Doesn't this need a Signed-off-by: Ross Maxfield <rmaxfiel@novell.com>?
> 
> People have been complaining that a patch should not retain the Signed-off-by
> line if the patch has been modified, because they do not sign-off the modified
> patch.  If a patch needs minor changes before it can be committed, we can
> either bounce it back to the author, which seems unnecessarily heavyweight, or
> do what Keir's done here, and sign-off the patch himself.  The From: line
> retains the audit trail, credit, and copyright, and it's clear that Keir
> himself thinks that this patch is acceptable.

This is not acceptable practice in my opinion. An alternative would be 
to add an Acked-by: Ross line to verify that the code is still ok'd per 
the DCO guidelines by the original author.

What would be even better is to follow the accepted practice for linux 
development, which is to bounce it back to the author with comments. In 
fact, please explain why we don't follow that practice again? If the 
answer is that it is too heavyweight please think again.

Mike Day

^ permalink raw reply

* Re: Re: [Xen-changelog] If the 'cdrom=' option is specified in the definition file but media is
From: Anthony Liguori @ 2006-04-10 20:54 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: Ross Maxfield, xen-devel, Hollis Blanchard
In-Reply-To: <20060410192930.GA12825@leeni.uk.xensource.com>

Ewan Mellor wrote:
> On Mon, Apr 10, 2006 at 01:29:13PM -0500, Anthony Liguori wrote:
>  
>   
>> Doesn't this need a Signed-off-by: Ross Maxfield <rmaxfiel@novell.com>?
>>     
>
> People have been complaining that a patch should not retain the Signed-off-by
> line if the patch has been modified, because they do not sign-off the modified
> patch.  If a patch needs minor changes before it can be committed, we can
> either bounce it back to the author, which seems unnecessarily heavyweight, or
> do what Keir's done here, and sign-off the patch himself.  The From: line
> retains the audit trail, credit, and copyright, and it's clear that Keir
> himself thinks that this patch is acceptable.
>   

I won't speak for Hollis (although I will CC him :-)) but my 
understanding is that the appropriate thing to do is check in the patch 
with the original Signed-off-by and then check in another patch on top 
of that with the necessary changes (this time, with just Keir's 
Signed-off-by).

I think the intention is that the original submitter needs to have a 
Signed-off-by to signify that the origin of the code is kosher (which is 
something Keir cannot do on his own if the code didn't originate from 
him).  Is this how other people understand it?

Regards,

Anthony Liguori

> Ewan.
>   

^ permalink raw reply

* Daily Xen Builds
From: David F. Barrera @ 2006-04-10 20:53 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

April 10, 2006,  using xen-unstable changeset:

changeset:   9592:1c03c45d0c06
tag:         tip
user:        ack@kneesa.uk.xensource.com
date:        Mon Apr 10 04:57:38 2006 +0100
summary:     fix x86_32 default linux builds

x86_32 (no PAE support)

   * SLES 9 SP2 on IBM xSeries 235(512MB RAM)
   * Builds and boots without problems
   * Able to create fully functional guest domains
   * Ran xm-test on all boxes

   ISSUES:

x86_32 (PAE)

     * SLES 9 SP2 on xSeries 335 and HS20 Blade 8843and FC4 on IBM
     xSeries 335s                 * Builds and boots without problems
     * Able to create fully functional guest domains
     * Ran xm-test on all boxes

   ISSUES:
     *  Bugzilla Bug 543 - domU: BUG: soft lockup detected on CPU#1!

x86_64 (SLES 9 SP2 IBM HS20 Blades 8843 41U)

   * Builds and boots without problems
   * Able to create fully functional guest domains
   * Ran xm-test on all boxes

   ISSUES:                 

--XM-TEST Results--

SUMMARY:

            Platform | PASS | FAIL | XPASS | XFAIL |
---------------------+------+------+-------+-------+
 hs20.1.sles9-x86_64 |  111 |    3 |     0 |     3 |
hs20.rhel4-x86_32pae |  110 |    4 |     0 |     3 |
     x235sles9nonpae |  111 |    3 |     0 |     3 |
          x335fc4pae |  110 |    4 |     0 |     3 |
    x335sles9_pae4gb |  111 |    3 |     0 |     3 |

-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                       Euripides



[-- Attachment #2: hs20.1.sles9-x86_64.report --]
[-- Type: text/plain, Size: 328 bytes --]

Xm-test execution summary:
  PASS:  111
  FAIL:  3
  XPASS: 0
  XFAIL: 3


Details:

XFAIL: 02_network_local_ping_pos 
	 ping loopback failed for size 65507. ping eth0 failed for size 65507.

XFAIL: 05_network_dom0_ping_pos 
	 Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos 
	 Ping failed for size 65507.


[-- Attachment #3: hs20.rhel4-x86_32pae.report --]
[-- Type: text/plain, Size: 401 bytes --]

Xm-test execution summary:
  PASS:  110
  FAIL:  4
  XPASS: 0
  XFAIL: 3


Details:

 FAIL: 01_migrate_localhost_pos 
	 xm migrate returned invalid 256 != 0

XFAIL: 02_network_local_ping_pos 
	 ping loopback failed for size 65507. ping eth0 failed for size 65507.

XFAIL: 05_network_dom0_ping_pos 
	 Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos 
	 Ping failed for size 65507.


[-- Attachment #4: x235sles9nonpae.report --]
[-- Type: text/plain, Size: 328 bytes --]

Xm-test execution summary:
  PASS:  111
  FAIL:  3
  XPASS: 0
  XFAIL: 3


Details:

XFAIL: 02_network_local_ping_pos 
	 ping loopback failed for size 65507. ping eth0 failed for size 65507.

XFAIL: 05_network_dom0_ping_pos 
	 Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos 
	 Ping failed for size 65507.


[-- Attachment #5: x335fc4pae.report --]
[-- Type: text/plain, Size: 399 bytes --]

Xm-test execution summary:
  PASS:  110
  FAIL:  4
  XPASS: 0
  XFAIL: 3


Details:

XFAIL: 02_network_local_ping_pos 
	 ping loopback failed for size 65507. ping eth0 failed for size 65507.

XFAIL: 05_network_dom0_ping_pos 
	 Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos 
	 Ping failed for size 65507.

 FAIL: 01_vcpu-pin_basic_pos 
	 xm vcpu-pin returned invalid 256 != 0


[-- Attachment #6: x335sles9_pae4gb.report --]
[-- Type: text/plain, Size: 328 bytes --]

Xm-test execution summary:
  PASS:  111
  FAIL:  3
  XPASS: 0
  XFAIL: 3


Details:

XFAIL: 02_network_local_ping_pos 
	 ping loopback failed for size 65507. ping eth0 failed for size 65507.

XFAIL: 05_network_dom0_ping_pos 
	 Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos 
	 Ping failed for size 65507.


[-- Attachment #7: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply

* [linux-lvm] moving a volume group from one SAN host to another (using powerpa th)
From: Humpherys Philip D Contr 309 CMXG/MXCD @ 2006-04-10 20:52 UTC (permalink / raw)
  To: 'linux-lvm@redhat.com'

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

I have a volume group built on one host.  I vgchange -an on it to
de-activate it, then I vgexport it.  The devices are presented to another
host.  I run a pvscan (and pvscan -e) on it and I don't see the devices, I
don't see an exported volume group.

 

No matching physical volumes found

 

Help?

 

-pdh


[-- Attachment #2: Type: text/html, Size: 2185 bytes --]

^ permalink raw reply

* hdlc_enet
From: Antonio Di Bacco @ 2006-04-10 20:51 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,

I want to use the hdlc_enet driver, to use both scc2 and scc4 connected 
together on a MBX card.
To get my hdlc_enet_init called shoudl I patch Space.c adding a list of hdlc 
devices?
Anyone could help?

Bye,
Antonio.

^ permalink raw reply

* Re: [Devel] [PATCH 4/7] uts namespaces: implement utsname namespaces
From: Serge E. Hallyn @ 2006-04-10 20:48 UTC (permalink / raw)
  To: Cedric Le Goater
  Cc: linux-kernel, Kirill Korotaev, herbert, sam, Eric W. Biederman,
	xemul, James Morris
In-Reply-To: <443A829E.1050902@fr.ibm.com>

Quoting Cedric Le Goater (clg@fr.ibm.com):
> Serge E. Hallyn wrote:
> > ...
> > -struct new_utsname system_utsname = {
> > -	.sysname	= UTS_SYSNAME,
> > -	.nodename	= UTS_NODENAME,
> > -	.release	= UTS_RELEASE,
> > -	.version	= UTS_VERSION,
> > -	.machine	= UTS_MACHINE,
> > -	.domainname	= UTS_DOMAINNAME,
> > +struct uts_namespace init_uts_ns = {
> > +	.kref = {
> > +		.refcount	= ATOMIC_INIT(2),
> > +	},
> > +	.name = {
> > +		.sysname	= UTS_SYSNAME,
> > +		.nodename	= UTS_NODENAME,
> > +		.release	= UTS_RELEASE,
> > +		.version	= UTS_VERSION,
> > +		.machine	= UTS_MACHINE,
> > +		.domainname	= UTS_DOMAINNAME,
> > +	},
> >  };
> >  
> > -EXPORT_SYMBOL(system_utsname);
> 
> this should problably be replaced with
> 
> EXPORT_SYMBOL(init_uts_ns);
> 
> or export init_utsname().

True, here's an updated version of the uts_ns introduction patch.

From: Serge Hallyn <serue@us.ibm.com>
Subject: [PATCH 4/7] This patch defines the uts namespace and some manipulators.

Adds the uts namespace to task_struct, and initializes a
system-wide init namespace.

It leaves a #define for system_utsname so sysctl will compile.
This define will be removed in a separate patch.

Changes:
	Export init_uts_ns.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>

---

 include/linux/init_task.h |    2 +
 include/linux/sched.h     |    2 +
 include/linux/utsname.h   |   43 +++++++++++++++++++++++++---
 init/Kconfig              |    8 +++++
 init/version.c            |   69 ++++++++++++++++++++++++++++++++++++++++-----
 kernel/exit.c             |    2 +
 kernel/fork.c             |    9 +++++-
 7 files changed, 121 insertions(+), 14 deletions(-)

087afa02b1165104da8352cbf35512cf0c681f2f
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 41ecbb8..21b1751 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -3,6 +3,7 @@
 
 #include <linux/file.h>
 #include <linux/rcupdate.h>
+#include <linux/utsname.h>
 
 #define INIT_FDTABLE \
 {							\
@@ -123,6 +124,7 @@ extern struct group_info init_groups;
 	.journal_info	= NULL,						\
 	.cpu_timers	= INIT_CPU_TIMERS(tsk.cpu_timers),		\
 	.fs_excl	= ATOMIC_INIT(0),				\
+	.uts_ns		= &init_uts_ns,					\
 }
 
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 541f482..97c7990 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -684,6 +684,7 @@ static inline void prefetch_stack(struct
 
 struct audit_context;		/* See audit.c */
 struct mempolicy;
+struct uts_namespace;
 
 enum sleep_type {
 	SLEEP_NORMAL,
@@ -807,6 +808,7 @@ struct task_struct {
 	struct files_struct *files;
 /* namespace */
 	struct namespace *namespace;
+	struct uts_namespace *uts_ns;
 /* signal handlers */
 	struct signal_struct *signal;
 	struct sighand_struct *sighand;
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index 8f0decf..e6ce607 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -1,5 +1,8 @@
 #ifndef _LINUX_UTSNAME_H
 #define _LINUX_UTSNAME_H
+#include <linux/sched.h>
+#include <linux/kref.h>
+#include <asm/atomic.h>
 
 #define __OLD_UTS_LEN 8
 
@@ -30,15 +33,47 @@ struct new_utsname {
 	char domainname[65];
 };
 
-extern struct new_utsname system_utsname;
+struct uts_namespace {
+	struct kref kref;
+	struct new_utsname name;
+};
+extern struct uts_namespace init_uts_ns;
+
+#ifdef CONFIG_UTS_NS
+
+extern struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns);
+extern struct uts_namespace *unshare_uts_ns(void);
+extern void free_uts_ns(struct kref *kref);
+
+static inline void get_uts_ns(struct uts_namespace *ns)
+{
+	kref_get(&ns->kref);
+}
+
+static inline void put_uts_ns(struct uts_namespace *ns)
+{
+	kref_put(&ns->kref, free_uts_ns);
+}
+
+#else
+static inline void get_uts_ns(struct uts_namespace *ns)
+{
+}
+static inline void put_uts_ns(struct uts_namespace *ns)
+{
+}
+#endif
 
-static inline struct new_utsname *utsname(void) {
-	return &system_utsname;
+static inline struct new_utsname *utsname(void)
+{
+	return &current->uts_ns->name;
 }
 
 static inline struct new_utsname *init_utsname(void) {
-	return &system_utsname;
+	return &init_uts_ns.name;
 }
 
+#define system_utsname init_uts_ns.name
+
 extern struct rw_semaphore uts_sem;
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 3b36a1d..8460e5a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -166,6 +166,14 @@ config SYSCTL
 	  building a kernel for install/rescue disks or your system is very
 	  limited in memory.
 
+config UTS_NS
+	bool "UTS Namespaces"
+	default n
+	help
+	  Support uts namespaces.  This allows containers, i.e.
+	  vservers, to use uts namespaces to provide different
+	  uts info for different servers.  If unsure, say N.
+
 config AUDIT
 	bool "Auditing support"
 	depends on NET
diff --git a/init/version.c b/init/version.c
index 3ddc3ce..983338a 100644
--- a/init/version.c
+++ b/init/version.c
@@ -11,22 +11,75 @@
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <linux/version.h>
+#include <linux/sched.h>
 
 #define version(a) Version_ ## a
 #define version_string(a) version(a)
 
 int version_string(LINUX_VERSION_CODE);
 
-struct new_utsname system_utsname = {
-	.sysname	= UTS_SYSNAME,
-	.nodename	= UTS_NODENAME,
-	.release	= UTS_RELEASE,
-	.version	= UTS_VERSION,
-	.machine	= UTS_MACHINE,
-	.domainname	= UTS_DOMAINNAME,
+struct uts_namespace init_uts_ns = {
+	.kref = {
+		.refcount	= ATOMIC_INIT(2),
+	},
+	.name = {
+		.sysname	= UTS_SYSNAME,
+		.nodename	= UTS_NODENAME,
+		.release	= UTS_RELEASE,
+		.version	= UTS_VERSION,
+		.machine	= UTS_MACHINE,
+		.domainname	= UTS_DOMAINNAME,
+	},
 };
+EXPORT_SYMBOL(init_uts_ns);
 
-EXPORT_SYMBOL(system_utsname);
+#ifdef CONFIG_UTS_NS
+/*
+ * Clone a new ns copying an original utsname, setting refcount to 1
+ * @old_ns: namespace to clone
+ * Return NULL on error (failure to kmalloc), new ns otherwise
+ */
+struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
+{
+	struct uts_namespace *ns;
+
+	ns = kmalloc(sizeof(struct uts_namespace), GFP_KERNEL);
+	if (ns) {
+		memcpy(&ns->name, &old_ns->name, sizeof(ns->name));
+		kref_init(&ns->kref);
+	}
+	return ns;
+}
+
+/*
+ * unshare the current process' utsname namespace.  Changes
+ * to the utsname of this process won't be seen by parent, and
+ * vice versa
+ *
+ * Return NULL on error (failure to kmalloc), new ns otherwise
+ *
+ * TODO: decide where this should be locked  (depends on how/where
+ * we decide to use this)
+ */
+struct uts_namespace *unshare_uts_ns(void)
+{
+	struct uts_namespace *old_ns = current->uts_ns;
+	struct uts_namespace *new_ns = clone_uts_ns(old_ns);
+	if (new_ns) {
+		current->uts_ns = new_ns;
+		put_uts_ns(old_ns);
+	}
+	return new_ns;
+}
+
+void free_uts_ns(struct kref *kref)
+{
+	struct uts_namespace *ns;
+
+	ns = container_of(kref, struct uts_namespace, kref);
+	kfree(ns);
+}
+#endif
 
 const char linux_banner[] =
 	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
diff --git a/kernel/exit.c b/kernel/exit.c
index 6c2eeb8..97c5405 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -34,6 +34,7 @@
 #include <linux/mutex.h>
 #include <linux/futex.h>
 #include <linux/compat.h>
+#include <linux/utsname.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
@@ -173,6 +174,7 @@ repeat:
 	spin_unlock(&p->proc_lock);
 	proc_pid_flush(proc_dentry);
 	release_thread(p);
+	put_uts_ns(p->uts_ns);
 	call_rcu(&p->rcu, delayed_put_task_struct);
 
 	p = leader;
diff --git a/kernel/fork.c b/kernel/fork.c
index 3384eb8..62e4479 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -44,6 +44,7 @@
 #include <linux/rmap.h>
 #include <linux/acct.h>
 #include <linux/cn_proc.h>
+#include <linux/utsname.h>
 
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -1119,6 +1120,8 @@ static task_t *copy_process(unsigned lon
 	/* Perform scheduler related setup. Assign this task to a CPU. */
 	sched_fork(p, clone_flags);
 
+	get_uts_ns(p->uts_ns);
+
 	/* Need tasklist lock for parent etc handling! */
 	write_lock_irq(&tasklist_lock);
 
@@ -1158,7 +1161,7 @@ static task_t *copy_process(unsigned lon
 		spin_unlock(&current->sighand->siglock);
 		write_unlock_irq(&tasklist_lock);
 		retval = -ERESTARTNOINTR;
-		goto bad_fork_cleanup_namespace;
+		goto bad_fork_cleanup_utsns;
 	}
 
 	if (clone_flags & CLONE_THREAD) {
@@ -1171,7 +1174,7 @@ static task_t *copy_process(unsigned lon
 			spin_unlock(&current->sighand->siglock);
 			write_unlock_irq(&tasklist_lock);
 			retval = -EAGAIN;
-			goto bad_fork_cleanup_namespace;
+			goto bad_fork_cleanup_utsns;
 		}
 
 		p->group_leader = current->group_leader;
@@ -1223,6 +1226,8 @@ static task_t *copy_process(unsigned lon
 	proc_fork_connector(p);
 	return p;
 
+bad_fork_cleanup_utsns:
+	put_uts_ns(p->uts_ns);
 bad_fork_cleanup_namespace:
 	exit_namespace(p);
 bad_fork_cleanup_keys:
-- 
1.1.6

^ permalink raw reply related

* Re: HSG80, DM, multipath issues
From: D. North @ 2006-04-10 20:48 UTC (permalink / raw)
  To: device-mapper development
In-Reply-To: <443AA3DF.3080404@free.fr>

Thus spake Christophe Varoqui (christophe.varoqui@free.fr):

> The one I used is "force a bounce per LUN just after driver loading", 
> which this snippet does :
> 
>        sg_start -s 1 /dev/$i


Thanks! ... This got me going enough to get a /dev/mapper/lun4p1...p3 up & running!
This was done manually from a 'rescue mode' boot of SuSE 10.

After trying the required commands on a running system, it's clear now that the
device mapper setup has to be done in the initrd if I expect to boot from this
array. No problem there... that's just a comment.

What is troubling me more at the moment is the difference between the device
mapper table setup commands created by the multipath command and how they
are different from what dm-mpath.c is actually expecting.

I downloaded 0.4.7 multipath tools & verified that they produce the same
table setup issues that I'm having trouble with from the 0.4.5 tool that
is current with SuSE 10. For example, the SuSE version of multipath command
produces this:
       0 443027195 multipath 0 0 2 1 round-robin 1 1 8:0 1000 round-robin 1 1 8:16 1000
Which produces the previously mentioned misparse in dm-mpath.c (my debugging mods)
       Apr 10 15:30:35 orthus-san kernel: nr_params is 1001, nr_selector_args = 1000, pg->nr_pgpaths is 8

Multipath tools 0.4.7 also causes the same diagnostic message (from my
debugging modifications), and it is sending in the same number of arguments
(14) to dm-mpath.c.  I don't, however, get the diagnostic message any more from
this version of multipath to determine what it is actually sending into
libdevmapper, so I am not, at the moment, absolutely certain that the argument
list is the same as 0.4.5.

To bypass the misparse, I can still use a command like this:
       # echo 0 443027195 multipath 0 0 2 1 round-robin 1 1 1 0 8:0 round-robin 1 1 1 0 8:16 | dmsetup create lun4

I have successfully set up a device mapper mapping that I can read & write
to from a rescue system, so the above command does actually work.

Unfortunately, if I correctly understand what I'm seeing, this means that the
current multipath tools 0.4.7 is incompatible with the dm_multipath module in
my 2.6.13-15.8 kernel. Also, this would seem to mean that multipathd is also
incompatible with this kernel.

Is anyone aware of a workaround or even a better identification for this
incompatibility?

Thanks!
-- 
D. North

^ permalink raw reply

* RE: Power-button event after resume from S3
From: Felix Kuehling @ 2006-04-10 20:47 UTC (permalink / raw)
  To: Yu, Luming; +Cc: linux-acpi, Matthew Tippett, Chang-Hwa Lee, Samuel Li
In-Reply-To: <554C5F4C5BA7384EB2B412FD46A3BAD11906E5@pdsmsx411.ccr.corp.intel.com>

On Fri, 2006-07-04 at 10:49 +0800, Yu, Luming wrote:
> >Are there plans for a real fix for this problem, either in the 
> >kernel or
> >in acpid?
> >
> 
> We need a  patch to handle the wakeup power-button event.
> Do you want to hack a patch for this?

Before working on a patch I'd like to be sure that there is a general
consensus that this is indeed The Right Way (TM) to fix the problem.
Whose blessing would a patch need before being accepted?

Thanks,
  Felix

> 
> Probably, you need to hack acpi_button_notify.
> like:
> 
> if (acpi_in_suspend)
> 	don't generate event.
> 
> --Luming
> 



^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.