Greg, > > > (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?
Good point. Erasing/writing the eeprom should only be done by root. I'll add that... The device ignores void data and switches back to the default configuration. > Also, you're still using "typedef" in the ioctl and firmware download > code. Not nice :) Hmm, seems like Bill missed to include my patch :-) Remember, I've sent you a CC: with the patch? > > > 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? It's just transmitted differently. The best way to think about it is a parallel port. You write data the serial way, but all the single bits get written to the pins. The only differenc is, that in the bit bang mode, the pins keep their state until you write new characters to them. That's all. > 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. How can another application open /dev/ttyUSB0 when I've locked it? How can this kind of locking be done with procfs? Thomas ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
