Hi,
On Tue, Feb 25, 2003 at 01:22:10PM -0800, Greg KH wrote:
> Ick, no, I don't like this. I think the scanner driver can actually get
> rid of all of these horrible locks to handle the disconnect/close mess
> by just using a reference count. To back this up, here's a patch that I
> just wrote for the scanner driver (it's on top of the two other patches
> you sent me) that adds a kobject and should handle the destruction of
> the device just fine when the last reference goes away.
kobject is nice but that won't help for 2.4 because there is no
kobject in 2.4 (right?). Or do i miss something? The idea was to find a
solution for the 2.4 crashes but test in 2.5 fisrt :-)
Or should I write a replacement for kobject for the 2.4 scanner driver?
Well, the patch compiles and I can scan. Looks like the scn object is
freed after (disconnection && close).
However, it doesn't (yet) solve the real problem: if I disconnect the
scanner while the device file is openend and then write to the scanner
the kernel crashes.
Example (pseudo code)
fd = open ("/dev/usb/scanner0")
[disconnect scanner now]
write (fd, some_data)
-->crash
So I still need some kind of flag "device no longer present", that's
checked in write/read/ioctl. Can I just use kobject for that? Is there
a kobject api function to do that? Or can I just use kobj->refcount > 1?
> I can't test the patch, as I don't have a scanner, and if this works, I
> think the "global" lock can go away, and much of the use of the
> per-device lock can disappear too. Especially as you are only allowing
> one user access to the device at a time.
I really don't know much about the reason for the locks. I thought the
scn_mutex was (originally) intended to lock the minor device table in
2.4. I don't see why it would be needed in 2.5 (even without the
kobject). Concerning scn->sem, removing it may be ok if scn->open and
scn->present is no longer used. But as I said, I'm not sure about that
locking stuff :-/
Does it make sense to invest more time in cleaning up the 2.5 code if it
can be only used in 2.5 and the scanner driver is supposed to go away
in 2.5 anyway? As I said, the only thing stops me from sysing "remove
it in 2.5" is that I don't know if I can handle interrupt transfers
with libusb/devio correctly, if that becomes necessary for a scanner
in future.
Bye,
Henning
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
