On Mon, Jul 01, 2002 at 11:59:04AM -0700, David Brownell wrote:
> >>-   if (!hotplug_path [0])
> >>-           return;
> >>-   if (in_interrupt ()) {
> >>-           dbg ("In_interrupt");
> >>-           return;
> >>-   }
> >>-   if (!current->fs->root) {
> >>-           /* statically linked USB is initted rather early */
> >>-           dbg ("call_policy %s, num %d -- no FS yet", verb, 
> >>dev->devnum);
> >>-           return;
> >>-   }
> >
> >Why take out these checks?  Aren't they good to keep around?
> 
> Except for the in_interrupt() they're duplicated in lower levels.
> So they're still around, no point in duplicating.
> 
> The in_interrupt() requirements are typically pushed to
> documentation, and in this case we know that it's always
> called from a thread context anyway.  Again, no point.

Ok, makes sense.

> >>-            * everything needs a smart agent and usbfs; or can rely on
> >>+            * otherwise needs a smart agent and usbfs; or can rely on
> >
> >Hm, this still doesn't look any clearer :)
> 
> But at least it's correct ... not everything needs usbfs. :)
> 
> 
> >>-   dbg ("kusbd: %s %s %d", argv [0], verb, dev->devnum);
> >>-   value = call_usermodehelper (argv [0], argv, envp);
> >>+   dbg ("%s %s %d", argv [0], verb, dev->devnum);
> >>+   (void) call_usermodehelper (argv [0], argv, envp);
> >>    kfree (buf);
> >>    kfree (envp);
> >>-   if (value != 0)
> >>-           dbg ("kusbd policy returned 0x%x", value);
> >
> >
> >Why throw away the return value?
> 
> Consistency (no other hotplug invocation does anything with
> it) and utility (nothing useful to be done with such issues).
> Before keventd was added, there was at least the possibility
> of doing something useful given such faults ... no longer.

well, I'd like to keep the value, for debugging if nothing else.  Doing:
        (void) foo();
is just a "bad thing", error values should be looked at and passed up.
No reason we should be the ones doing it wrong, just because everyone
else does.

And hopefully most of these hotplug calls will get merged together into
the driverfs core soon, and we remember to pay attention to the return
value there :)

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to