Re: When was /dev/cua* depreciated?

On Sun, 09 Apr 2006, Jonathan Buzzard wrote:
/*
* Prepare the full-path file names of LOG/Configuration.
*/
sprintf(buf,"%s/npreal2d.cf", workpath); /* Config file name */
sprintf(EventLog,"%s/npreal2d.log", workpath); /* Log file name */

/*
* Open configuration file:
*/
ConfigFd = fopen(buf, "r");

Personally I would just go with a #define, but hey.

They probably haven't heard of string literal concatenation. It's an
ANSI feature, after all, and they seem unaware of anything as recent as
1989.

Their attempts at doing name lookup and daemonization have to be seen to
be believed.

They don't actually work.

How shocking.

,----
| /* stop daemon (npreal2d) */
| memset(tmpstr, '\0', 1024);
| sprintf(tmpstr, "ps -ef | grep npreal2d |");
| sprintf(tmpstr, "%s awk '$0 !~ /grep/ {system(\"kill -15 \"$2)}'", tmpstr);
| system(tmpstr);
`----

It is pretty incredible, but I never actually seen the installer work! I

I am again simply stunned (but that's because I'm thick with cold).

have always needed to patch it together by hand to work. There idea of an
init.d script is pretty funny as well

/usr/lib/npreal2/driver/mxloadsvr
modprobe npreal2 ttymajor=33 calloutmajor=38 verbose=0

.... but that first script edits startup scripts itself! It looks like they
wanted to make it dual-mode (there's a command-line parameter that says
if it should modify startup scripts or not), but, well...

,----
| if (makenode == LOADMODULE) {
[...]
| sprintf(tmpstr, "modprobe npreal2 ttymajor=%d calloutmajor=%d verbose=0", ttymajor, calloutmajor);
| system(tmpstr);
| }
|
| // if (makenode >= LOADNODE) {
[...]
`----

Yeah, the commented-out if statement. This stuff is even worse than
xterm.

The config file parser is lovely and robust; spaces throw it off, as do
tabs in the wrong places. The parser is duplicated in multiple files,
with different semantics in each file.

You might be getting the gist of why I want to rework it into something
sane :-)

To save future victims from having their brains dribble out of their ears?
(Excuse me, I need to go and change the bandage. I figure that's another
5 IQ points lost with this post alone.)

You managed to find them use a #else in a #ifdef, they usually go for
something like this

#ifndef STREAM
signal (SIGTERM, ( (void (*)()) wait_handle) );
#endif
#ifdef STREAM
signal (SIGTERM, wait_handle);
#endif

Joy. Still at least they didn't do one thing I saw at work today:

#ifdef WE_HANDLE_BONDS
/* do something */
#endif
#if WE_HANDLE_BONDS
/* do something entirely different */
#else
/* do a third thing */
#endif

But wait a minute Linux does not do streams...

These guys don't look like the facts disturb them. (Just using signal()
rather than sigaction() would normally be a warning sign, but sigaction()
is probably *far* too nifty-k00l-new-stuff for this lot.)

And that's just the installer! I haven't even looked at the kernel code
(the largest file by a considerable margin) because I don't dare. All I
can say is that if you dare run kernel code written by people with these
l33t skillz, you're a braver man than I.

Actually the kernel module bit is the best quality by far, and seems to
work fairly reliably.

I guess that they had to hire someone who know something about Linux for
that because their existing userbase of last-wrote-a-program-in-1983 monkeys
couldn't cope with it. Why not ask said person to write the rest, too?

The way it works is that the demon sits there and does the actual talking
to the serial/ethernet converter on the network, and pass the results to
the kernel driver which then communicates the results with end user
programs through normal looking /dev/tty devices.

But, er, why do you need a kernel driver for that at all? Just make the
daemons talk via a PTY, or via a suitable protocl layer like pppd does.
(Preferably the former, the TTY layer in the kernel is still a bit nasty.)

First step is to clean up the demon code and in combination with a sane
init.d script make it do everything else that is necessary for correct
operation.

s/clean up/rewrite/ ;)

The series of mx* programs can then be junked, though they are
junk to begin with.

Indeed.

Problem is there are few serial to ethernet converters that have any sort
of Linux support, and I did not pick the Moxa devices.

Even if you did pick them, it's rare that we get a chance to see the
quality of the software that comes with our hardware. I've always
assumed that any shipped software will be entirely useless and must be
discarded: it's served me well so far (although this laser printer reached
new depths with a CD that wouldn't even spin).

--
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
because bringing Windows into the picture rescaled "brokenness" by
a factor of 10.' --- Peter da Silva
.

Relevant Pages