Features Download
From: Oleg Verych <olecom-sQnj9it0DRqJcxsJZ+we5w <at> public.gmane.org>
Subject: aiding text editing + RFC: ti_usb-serial: userspace firmware, internal cfg. change, cleanup
Newsgroups: gmane.linux.usb.general
Date: Tuesday 15th January 2008 04:46:48 UTC (over 9 years ago)
@ Wed, Nov 14, 2007 at 08:10:51PM +0100, olecom:
> == Wed, Nov 14, 2007 at 05:48:01PM +0000, Alan Cox ==
> > > > Please run this through scripts/checkpatch.pl first and fix all of
> > > > warnings.
> > > 
> > > How nice, you have time to write this to me. I wonder how frequently
> > > 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.

Actually, there's something academic GUI based for Java.


= Bonus. =

> ==
> 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.

A new TIUSB based EZ430-RF2500 device[0] is turned to be a HID, device
for pretty much same task -- programmer/debugger interface for TI
MSP430 controllers. It now has a back-link, which is a serial link to
the uC under development.

[0] http://focus.ti.com/graphics/tool/eZ430-rf2500_500x418.jpg

IMHO this one hits problems, i was trying to discuss last year about
Linux USB "drivers". Making main tool's interface different from the
serial, which now is an optional back-link, have problems. One actual
device (ti usb 3410) by loading different firmware, can become quite
different end user usb one. And it has serial link in addition to the
main interface.

It's obviously for me, that this was made for users to do not mix
all-in-one serial interfaces and troubling TI support. But it also
shows clearly, that driver must be split into parts:

* a real usb driver part (attaching, fw loading)
* usb interface part (serial, HID+serial, etc.)

> ==
> 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,
> 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.
> ____
CD: 3ms