> > > 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. > > That would be a good reason to check for valid data, right?
A complete valid data check would be too much for kernel space, but I could add a check if the CRC add the end of the eeprom is correct. Would that be sufficient? > > How can another application open /dev/ttyUSB0 when I've locked it? > > How do you "lock" a port, using flock(2)? If another application > doesn't try to also get the lock, but rather just use the port, then it > can open it just fine, right? But this is true for all other handshaking-manipulations, isn't it? I can just open a port and reset RTS/CTS, can't I? One thing I forgot to mention: The bit bang handshaking mode is only valid per application. If another application opens /dev/ttyUSB0, ftdi_open() does a chip-reset and the bit bang mode is gone. 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
