cvs commit: src/sys/dev/usb ugen.c

[Brian Fundakowski Feldman]

On Wed, Sep 08, 2004 at 02:58:46PM -0600, M. Warner Losh wrote:
> It turns out that Brian's change typically is the same as the old
> code.  However, there are a few cases where it isn't:
> 
> (1) Where the application doesn't close the device when it gets an
>     error.  Stupid application, I know, but in this case the device
>     never detaches.  This is one of the things that caused our
>     appliction to die with the new code, but not the old code.  phk's
>     work with deadfs and dev_t ref counting may help here.
> 
>     A simple cat /dev/ugenX.Y would behave the same both ways, but
>     buggy applications do behave differently.
> 
> (2) It changes the timing of things such that my uhci controller
>     panics a little more often.  This panic is 'related' to detach,
>     but not exactly directly.  This seems related to interrupt load
>     and timing, but could be something else, like loadable modules.
> 
> I'm not sure what the right thing to do architecturally about #1 is,
> so for the moment I'm going to leave the change backed out.  However,
> I'll start a discussion on arch@ to see if some consensus can develop
> as to the right thing to do in general.
> 
> I'd also like to appologize to Brian for backing things out w/o
> talking to him first.  Like I said before, I let my frustration at
> wasted time get the better of me.

Either way, we should be able to fix "my" problem with the close()
operation panicking the system easily by modifying the detach
routine to wait for closes to happen without screwing with the
refcount logic.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
_______________________________________________
cvs-all at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe at freebsd.org"