On Tue, Mar 11, 2003 at 12:20:25AM +0100, Thomas Jarosch wrote: > > (but if you do, watch out for the security problems in your ioctl > > implementation, it didn't look secure at first glance...) > > Ooops :-) What's wrong with it?
You're letting any user do this ioctl. If that's ok, fine. You are also accepting data directly from the user, without validating the input at all. It looks like you can send a mis-formed data packet to the device by doing this. What happens to the device if you do that? Also, you're still using "typedef" in the ioctl and firmware download code. Not nice :) > > As for what's the odds of getting this into 2.4.21, I don't know. > > Let's see the code and work from there. > > Oh, and any reason you just can't use usbfs for this right now? > > Since you are changing the driver to not work like a tty driver anymore, > > doing everything from userspace might make more sense. > > Hehe, I was wrong about using procfs for the driver in my previous answer: > > Entering the bitbang mode should be done per application (like > setting RTS/CTS) and not at a global level. Imagine it like another > "handshaking" mode. After activation, the data is still written > char-by-char to the tty. Again, why not do this from userspace with a userspace driver? And if the data is written character by character, then how does this mode differ from a normal clocked serial line output? Also, sysfs and procfs can be used on a per device level. Your ioctl does not work on a per-application level, as anyone who opens the device, and then sets the mode, can have another program open the same port and still remain in that mode. 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
