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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.