Re: RFC: ti_usb-serial: userspace firmware, internal cfg. change, cleanup
Oleg Verych <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Organization | Palacky University in Olomouc, experimental physics department |
| Message-ID | <[email protected]> |
== Wed, Nov 14, 2007 at 05:48:01PM +0000, Alan Cox == > > > Please run this through scripts/checkpatch.pl first and fix all of those > > > warnings. > > > > How nice, you have time to write this to me. I wonder how frequently you > > did same for last, say, 9 years with your USB writings. > > We didn't have checkpatch nine years ago, and I've been fixing up a ton > of USB serial drivers as a result. Please use checkpatch is the right > thing to say - its what Andrew just told me to go do as well and he's > right. Alan. I know that. And i appreciate style fixes. But if tools are there for quite some time, and sources still have trivial whitespace damage, this is not serious. Going my usual flame-way, i'd like to say, that unless cause will be cured, any dealing with consequences will be a waste of time. As history and current state shows, making usable syntax highlighting and general, as well as particular, aid for text editors is unsolvable problem. Even for such simple thing as C. Those CS professors still teaching compilers, without f*cking trivial application of the parsers to produce (at least) comprehensive, checking, analyzing, aiding syntax highlighting, not saying about other simple text processing. MUA problems with Linus looking on (broken) text via `od` are not funny. It's just complete joke. == Driver. Even if official maintainer, who wanted 5 blobs in addition to two, did say something 9 month ago, i see no progress. The only one is no such driver in Debian. It's not a religion, it's just a style; managing and programming style. Managing, because any ``userspace'' problem is IMHO hand-waving. Support is Cc'ed and payed for making information available. I've choose neutral meaningful filenames, that can be very easily symlinked or copied ``for users''. Having and extending driver for per-device blobs is not general usecase, thus there's no driver update so far. If `udevd --daemon` or `udev --notdaemon` with sysfs are in trouble, then it's not my problem. == The very small and cute usb-based development tool for MSP430 controllers (very low power and smart clocks, qualified mixed-signal processing and good CPU speed) -- most user-(i.e. embedded developer)-friendly device, is f*cked up by programmers. With such `official' driver, most people can not deal with udev crap easily, and more importantly with actual hardware study and work. And after making things basically working one cannot go further inside same *small* device -- to hack usb interface itself *easily*, by just making another firmware file under same symlink in '/lib/firmware'. If most of the LKML crowd are happy to hack off on every new -rc, it doesn't mean every skilled programmer must know how to make that fine driver in linux work, to patch, to build, to configure. But if one going to hack this driver, there will be a big surprise. 30k of 99% of time useless bloat in the fine kernel, not saying about obvious efficient programming. ____ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel