Re: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On 7/20/07, Neil Brown <[EMAIL PROTECTED]> wrote: On Thursday July 19, [EMAIL PROTECTED] wrote: > On Thu, Jul 19, 2007 at 10:16:14AM +1000, Neil Brown wrote: > > On Wednesday July 18, [EMAIL PROTECTED] wrote: > > > OK, here I'm still confused--what should we be doing instead? > > > > Cast the variable to a type that printf knows about. > >seq_printf(m, ",anonuid=%d", (int)anonu); > > > > Or maybe cast it to (long) and use %ld, just in case... > > OK. In the event that uid_t some day ceases to eventually become an > int, will the casts help, or will they just suppress useful warnings? Probably not. Just leave it as it is. > > > Note the stray 's' in the current patch, after the comma! > > Sharp eyes, thanks! I'll make a patch. Uh, any objection if I print > all those uid's as unsigned while I'm at it? I wondered about that too. I think we have completely removed the fiction that 'nobody' is '-2' rather than '65534' so it should be both safe and sensible to make them unsigned. Ummm ... sorry for butting in here :-) But uid_t is always unsigned, yes. - 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: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On Thursday July 19, [EMAIL PROTECTED] wrote: > On Thu, Jul 19, 2007 at 10:16:14AM +1000, Neil Brown wrote: > > On Wednesday July 18, [EMAIL PROTECTED] wrote: > > > OK, here I'm still confused--what should we be doing instead? > > > > Cast the variable to a type that printf knows about. > >seq_printf(m, ",anonuid=%d", (int)anonu); > > > > Or maybe cast it to (long) and use %ld, just in case... > > OK. In the event that uid_t some day ceases to eventually become an > int, will the casts help, or will they just suppress useful warnings? Probably not. Just leave it as it is. > > > Note the stray 's' in the current patch, after the comma! > > Sharp eyes, thanks! I'll make a patch. Uh, any objection if I print > all those uid's as unsigned while I'm at it? I wondered about that too. I think we have completely removed the fiction that 'nobody' is '-2' rather than '65534' so it should be both safe and sensible to make them unsigned. NeilBrown - 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: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On Thu, Jul 19, 2007 at 10:16:14AM +1000, Neil Brown wrote: > On Wednesday July 18, [EMAIL PROTECTED] wrote: > > On Fri, Jul 13, 2007 at 12:29:33AM -0700, Andrew Morton wrote: > > > On Tue, 10 Jul 2007 12:27:37 +1000 NeilBrown <[EMAIL PROTECTED]> wrote: > > > > > > > +static void exp_flags(struct seq_file *m, int flag, int fsid, > > > > + uid_t anonu, uid_t anong, struct nfsd4_fs_locations > > > > *fsloc) > > > > +{ > > > > + show_expflags(m, flag, NFSEXP_ALLFLAGS); > > > > if (flag & NFSEXP_FSID) > > > > - seq_printf(m, "%sfsid=%d", first++?",":"", fsid); > > > > + seq_printf(m, ",fsid=%d", fsid); > > > > if (anonu != (uid_t)-2 && anonu != (0x1-2)) > > > > - seq_printf(m, "%sanonuid=%d", first++?",":"", anonu); > > > > + seq_printf(m, ",sanonuid=%d", anonu); > > > > > > It's a bit presumptuous to print a uid_t with "%d". Fortunately it > > > will work OK with all the present architectures. > > > > > > But in general: be cautious when feeding opaque types to printk. > > > > OK, here I'm still confused--what should we be doing instead? > > Cast the variable to a type that printf knows about. >seq_printf(m, ",anonuid=%d", (int)anonu); > > Or maybe cast it to (long) and use %ld, just in case... OK. In the event that uid_t some day ceases to eventually become an int, will the casts help, or will they just suppress useful warnings? > Note the stray 's' in the current patch, after the comma! Sharp eyes, thanks! I'll make a patch. Uh, any objection if I print all those uid's as unsigned while I'm at it? --b. - 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: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On Wed, 18 Jul 2007 19:05:55 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> wrote: > On Fri, Jul 13, 2007 at 12:29:33AM -0700, Andrew Morton wrote: > > On Tue, 10 Jul 2007 12:27:37 +1000 NeilBrown <[EMAIL PROTECTED]> wrote: > > > > > +static void exp_flags(struct seq_file *m, int flag, int fsid, > > > + uid_t anonu, uid_t anong, struct nfsd4_fs_locations *fsloc) > > > +{ > > > + show_expflags(m, flag, NFSEXP_ALLFLAGS); > > > if (flag & NFSEXP_FSID) > > > - seq_printf(m, "%sfsid=%d", first++?",":"", fsid); > > > + seq_printf(m, ",fsid=%d", fsid); > > > if (anonu != (uid_t)-2 && anonu != (0x1-2)) > > > - seq_printf(m, "%sanonuid=%d", first++?",":"", anonu); > > > + seq_printf(m, ",sanonuid=%d", anonu); > > > > It's a bit presumptuous to print a uid_t with "%d". Fortunately it > > will work OK with all the present architectures. > > > > But in general: be cautious when feeding opaque types to printk. > > OK, here I'm still confused--what should we be doing instead? > Nothing? I was just having a little self-muse. If one was really anal, one could typecast it to an unsigned long long in the printk, then feel smug when we switch to 64-bit uid's. - 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: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On Wednesday July 18, [EMAIL PROTECTED] wrote: > On Fri, Jul 13, 2007 at 12:29:33AM -0700, Andrew Morton wrote: > > On Tue, 10 Jul 2007 12:27:37 +1000 NeilBrown <[EMAIL PROTECTED]> wrote: > > > > > +static void exp_flags(struct seq_file *m, int flag, int fsid, > > > + uid_t anonu, uid_t anong, struct nfsd4_fs_locations *fsloc) > > > +{ > > > + show_expflags(m, flag, NFSEXP_ALLFLAGS); > > > if (flag & NFSEXP_FSID) > > > - seq_printf(m, "%sfsid=%d", first++?",":"", fsid); > > > + seq_printf(m, ",fsid=%d", fsid); > > > if (anonu != (uid_t)-2 && anonu != (0x1-2)) > > > - seq_printf(m, "%sanonuid=%d", first++?",":"", anonu); > > > + seq_printf(m, ",sanonuid=%d", anonu); > > > > It's a bit presumptuous to print a uid_t with "%d". Fortunately it > > will work OK with all the present architectures. > > > > But in general: be cautious when feeding opaque types to printk. > > OK, here I'm still confused--what should we be doing instead? Cast the variable to a type that printf knows about. seq_printf(m, ",anonuid=%d", (int)anonu); Or maybe cast it to (long) and use %ld, just in case... Note the stray 's' in the current patch, after the comma! NeilBrown - 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: [NFS] [PATCH 013 of 20] knfsd: nfsd: factor out code from show_expflags
On Fri, Jul 13, 2007 at 12:29:33AM -0700, Andrew Morton wrote: > On Tue, 10 Jul 2007 12:27:37 +1000 NeilBrown <[EMAIL PROTECTED]> wrote: > > > +static void exp_flags(struct seq_file *m, int flag, int fsid, > > + uid_t anonu, uid_t anong, struct nfsd4_fs_locations *fsloc) > > +{ > > + show_expflags(m, flag, NFSEXP_ALLFLAGS); > > if (flag & NFSEXP_FSID) > > - seq_printf(m, "%sfsid=%d", first++?",":"", fsid); > > + seq_printf(m, ",fsid=%d", fsid); > > if (anonu != (uid_t)-2 && anonu != (0x1-2)) > > - seq_printf(m, "%sanonuid=%d", first++?",":"", anonu); > > + seq_printf(m, ",sanonuid=%d", anonu); > > It's a bit presumptuous to print a uid_t with "%d". Fortunately it > will work OK with all the present architectures. > > But in general: be cautious when feeding opaque types to printk. OK, here I'm still confused--what should we be doing instead? --b. - 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/