Re: When was /dev/cua* depreciated?
- From: Jonathan Buzzard <jonathan@xxxxxxxxxxxxx>
- Date: Sun, 09 Apr 2006 15:22:08 +0100
On Sun, 09 Apr 2006 01:05:10 +0100, Nix wrote:
On Sat, 08 Apr 2006, Jonathan Buzzard spake:
Can anyone remember in which kernel version the /dev/cua* devices where
depreciated? I seem to remember it was in 2.2 but after googling a bit I
cannot find any references.
They were deprecated in 2.1.90pre2.
That's what I thought, as I remember them being in 2.0 and gone in 2.2, so
figured they must have gone in 2.1.x sometime.
[SNIP]
If you want to see how bad they are take a look here
http://www.moxa.com/drivers/Nport/Admin/Linux/V1.12/npreal2_1.12.tgz
Gotta love the directory name in the tarball:
,----
| nix@hades 7 /tmp% tar tf npreal2_1.12.tgz
| tmp/moxa/
| tmp/moxa/npreal2.c
[...]
`----
Their list of required software is a hoot, including `gawk-3.1.1.9 or above',
which is a neat trick given that the FSF has never released a gawk with that
version number. I'd bet they just took the versions on the machine they
built it on and repeated those, except that those versions include `ld.so 1.7.14',
and I don't believe they were using a libc5 box in this day and age.
... OK, so it has a kernel module in it.
The starting point would be half of it is written in K&R C, closely
followed up with the fact the config file is under /usr/lib as is the log
file!!!
... and the sysadmin binaries are helpfully located in /usr/lib/npreal2/driver.
I suppose that's better than tmp/moxa/... all these paths are helpfully
hardwired into numerous C files (#define? what is that?)
This is the bit I like
/*
* 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.
Their attempts at doing name lookup and daemonization have to be seen to
be believed.
They don't actually work.
The installer shell script has no shebang at the top. I hope you're
using bash as /bin/sh, everyone. It calls a C program which *prepends*
stuff onto rc scripts according to a rough guess as to your distro. If
you use the string `mxloadsvr' in your startup files for whatever reason,
the uninstaller will remove it.
The whole thing is utterly rife with tmp races and insane uses of system(),
e.g. (one example of many):
,----
| /* 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
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
I hope you weren't attached to that big simulation simenpreal2d you were
running. And I hope you don't have PS_PERSONALITY set to anything too
unusual. And I really hope your PATH is reasonably normal.
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 :-)
There are some lovely macros:
,----
| #ifdef _DEBUG_PRINT
| #define DBG_PRINT printf
| #else
| #define DBG_PRINT if (0) printf
| #endif
`----
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
But wait a minute Linux does not do streams...
[SNIP]
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. There is a driver for a Moxa serial port PCI card in
the kernel, so perhaps they no what needs to be done for the kernel code.
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.
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. The series of mx* programs can then be junked, though they are
junk to begin with.
Problem is there are few serial to ethernet converters that have any sort
of Linux support, and I did not pick the Moxa devices.
JAB.
--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom. Tel: +44 1661-832195
.
- Follow-Ups:
- Re: When was /dev/cua* depreciated?
- From: Nix
- Re: When was /dev/cua* depreciated?
- References:
- When was /dev/cua* depreciated?
- From: Jonathan Buzzard
- Re: When was /dev/cua* depreciated?
- From: Nix
- When was /dev/cua* depreciated?
- Prev by Date: Re: Someone's knocking on my door
- Next by Date: Re: Someone's knocking on my door
- Previous by thread: Re: When was /dev/cua* depreciated?
- Next by thread: Re: When was /dev/cua* depreciated?
- Index(es):
Relevant Pages
|
