Re: Totally broken PCI PM calls

[Linus Torvalds]

On Sun, 24 Oct 2004, Pavel Machek wrote:
> 
> Ok, after -Wbitwise for sparse, strict typechecking seems to
> work. Unfortunately, it produces a *lot* of noise, for code such as
> 
> static ssize_t disk_show(struct subsystem * subsys, char * buf)
> {
>         return sprintf(buf, "%s\n", pm_disk_modes[pm_disk_mode]);
> }
> 
> ...where pm_disk_mode is __bitwise. That is not really what we
> want. Would it be possible to get something similar to __bitwise where
> arithmetic is still okay to do?

I'll try to get to it - I've spent the last two days on sparse making sure 
that I can do flow-control checking (things like "a function that gets a 
spinlock needs to release it"), and it will take a while before I get out 
of it.

But yes, I think it makes sense to have a "unique type" thing that allows 
arithmetic. And I think it makes sense to have another unique type that 
disallows _all_ operations (ie truly opaque cookies, where the only valid 
op is to compare it with another cookie).

Maybe Al is interested..

		Linus

---
> With __bitwise, I'd need to do:
> 
> @@ -292,15 +297,15 @@
>         int i;
>         int len;
>         char *p;
> -       u32 mode = 0;
> +       suspend_disk_method_t mode = 0;
> 
>         p = memchr(buf, '\n', n);
>         len = p ? p - buf : n;
> 
>         down(&pm_sem);
> -       for (i = PM_DISK_FIRMWARE; i < PM_DISK_MAX; i++) {
> +       for (i = (int __force) PM_DISK_FIRMWARE; i < (int __force) PM_DISK_MAX; i++) {
>                 if (!strncmp(buf, pm_disk_modes[i], len)) {
> -                       mode = i;
> +                       mode = (suspend_disk_method_t __force) i;
>                         break;
>                 }
>         }
> 
> 
> ...thats ugly.
> 
> 								Pavel
> -- 
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/